Programmable Forth Audio Processor

[Christopher Lozinski]

Thanks to all of you, my understanding of the technology and the market continues to improve. 16 bit Forth machines are very space and memory efficient, but the problem is that real time control applications use more than 16 bits of accuracy’s and you really do not want to be doing stack operations on doubles. Dup is two deep, Over is 4 deep, but rot is 6 deep. Sure at 60Mhz there is enough time, but it is just ugly. So I need an application which uses 16 bit data or less. AFAIK, the only data which is 16 bits wide is audio quality CD, so my focus is now on an audio processor for musicians, hearing aids, and echolocation. There are a lot of older Forth developers who need hearing aids, and in the US, they are no longer regulated. 

Here is the $35 board I am targeting.

https://tinyvision.ai/products/pico-ice

This board, can happily fit 8 * 16 bit stack machines.
Each will have a hard core multiplier and 128Kbits of memory. That is 8K 16bit words. If needed, I can even go t0 16 processors, 8 with hard core multipliers.

This processor will be very different from the J1 and Mecrisp processors. They are optimized to be as small as possible, with only 16 instructions. Each one only takes 160 LUT’s, but I have 5260 LUTs on this board. With all of that logic fabric, I can happily have 32 instructions instead of the J1’s 16. That makes this closer to Ting’s eForth EP16/24/32. Of course Ting had 3 different code bases, but with modern tools like Python’s Amaranth, or Java’s SpinalHDL, I should be able to generate 16, 24 and 32 bit cpus all from the same code base.

The J1 depends on dual port memory. It can read or write to memory at the same time that it is fetching the next instruction. And one needs that to be able to edit code. Sadly the inexpensive Lattice boards are mostly single port memory. So I have to use a Harvard architecture, where code and memory are separate. MicroCore does this. I suspect Ting also did this.

I will also need some logic dedicated to audio processing. I am not yet sure what it will be. There may need to be a shift register to store some history from two or three microphones for cross-correlation and edge detection. There may need to be some flags for when the next bit of audio becomes available.

So I see a family of many core eForth CPU’s, all in Amaranth, taking the best ideas from many of the existing Forth cpus. Initially my focus will be on 16 bits for audio, later on 24 bits for video. If someone actually needs a 32 bit processor, I will release that as well.

Particular thanks to @Lorum Ipsum for pointing out that the low end Lattice boards are also low power. Thanks to Juergen Pintaske for connecting me to the Facebook Forth group, and to a real time control expert who pointed out that they need 32 bit data. Thanks to the the Mecrisp-Ice author for pointing out that the Lattice Ice40 boards are single port. Thanks to the Core-1 lead for all of his great advice. Thanks to the 22 people on Facebook who like this idea, and to the one person who already wants to buy my many core Forth cpu!

[Lorem Ipsum]

On Thursday, August 10, 2023 at 3:17:28 AM UTC-4, Christopher Lozinski wrote:
> Thanks to all of you, my understanding of the technology and the market continues to improve. 16 bit Forth machines are very space and memory efficient, but the problem is that real time control applications use more than 16 bits of accuracy’s and you really do not want to be doing stack operations on doubles. Dup is two deep, Over is 4 deep, but rot is 6 deep. Sure at 60Mhz there is enough time, but it is just ugly. So I need an application which uses 16 bit data or less.

You've lost me. Rather than designing a CPU for an applicatiion, you want to design an application for a CPU??? What???

> AFAIK, the only data which is 16 bits wide is audio quality CD, so my focus is now on an audio processor for musicians, hearing aids, and echolocation. There are a lot of older Forth developers who need hearing aids, and in the US, they are no longer regulated. 

Here is the $35 board I am targeting.
>
> https://tinyvision.ai/products/pico-ice
>
> This board, can happily fit 8 * 16 bit stack machines.
> Each will have a hard core multiplier and 128Kbits of memory. That is 8K 16bit words. If needed, I can even go t0 16 processors, 8 with hard core multipliers.

Why are you locked into 16 bits? Audio actually needs more than 16 bits, because the calculations need to use more bits, in order to not lose precision in the process. It is very common to use 24 bits in the data and ALU paths for audio work. Any musician is going to drop a 16 bit device in the trash, because the artifacts will be audible.

> This processor will be very different from the J1 and Mecrisp processors. They are optimized to be as small as possible, with only 16 instructions. Each one only takes 160 LUT’s, but I have 5260 LUTs on this board. With all of that logic fabric, I can happily have 32 instructions instead of the J1’s 16. That makes this closer to Ting’s eForth EP16/24/32. Of course Ting had 3 different code bases, but with modern tools like Python’s Amaranth, or Java’s SpinalHDL, I should be able to generate 16, 24 and 32 bit cpus all from the same code base.

Why do you want more instructions? Not only will more instructions use more resources, they will make the processor slower. You can counter this by using long instruction words, to reduce or eliminate decoding, but there will be a limit. You will also improve speed by limiting all instructions to 1 clock cycle. When you need multiple clock cycles, you have to then have a counter, which becomes part of the instruction for decode purposes.

There is a reason why most people designing CPUs for Forth, don't call them Forth processors. They call them MISC (Minimal Instruction Set Computer). The use of Forth as the language for writing code is irrelevant. Minimizing the CPU and instruction sizes gains speed.

This is why I tell people to work on paper first. Once you write some code for your processor, you will find your additional instructions are seldom used and actually slow the processor overall.

> The J1 depends on dual port memory. It can read or write to memory at the same time that it is fetching the next instruction. And one needs that to be able to edit code. Sadly the inexpensive Lattice boards are mostly single port memory. So I have to use a Harvard architecture, where code and memory are separate. MicroCore does this. I suspect Ting also did this.

??? Are you talking about memory external to the CPU?

Harvard is good for stack machines. The instruction memory is seldom accessed, other than when loading. You can put constants in the data memory. The dual port memory is internal to an FPGA and is available in nearly every device that is still in production.

> I will also need some logic dedicated to audio processing. I am not yet sure what it will be. There may need to be a shift register to store some history from two or three microphones for cross-correlation and edge detection. There may need to be some flags for when the next bit of audio becomes available.

You are trying to optimize your code, not only before you've written the code, but before you've designed the CPU. It will be so much better if you don't try to do everything at once. Just try designing a stack processor and see where the issues are. First, you will need to figure out how to find logic paths slowing your clock cycle. Then write some code to do something useful. Run it in the simulator and get some timing data. No need for hardware even. Get some experience and learn what areas you need to come up to speed in.

> So I see a family of many core eForth CPU’s, all in Amaranth, taking the best ideas from many of the existing Forth cpus. Initially my focus will be on 16 bits for audio, later on 24 bits for video. If someone actually needs a 32 bit processor, I will release that as well.
>
> Particular thanks to @Lorum Ipsum for pointing out that the low end Lattice boards are also low power. Thanks to Juergen Pintaske for connecting me to the Facebook Forth group, and to a real time control expert who pointed out that they need 32 bit data. Thanks to the the Mecrisp-Ice author for pointing out that the Lattice Ice40 boards are single port. Thanks to the Core-1 lead for all of his great advice. Thanks to the 22 people on Facebook who like this idea, and to the one person who already wants to buy my many core Forth cpu!

Good luck.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

[Heinrich Hohl]

On Thursday, August 10, 2023 at 9:17:28 AM UTC+2, Christopher Lozinski wrote:
> AFAIK, the only data which is 16 bits wide is audio quality CD, so my focus is now on an audio processor
> for musicians, hearing aids, and echolocation.

I don't think that this will work out well.

In the field of audio DSP (digital signal processing), we usually record audio with a
bit depth of 24 bits.

In the DAW (digital audio workstation), the audio signal is converted to 32-bit FP or 64-bit FP.
Most DAWs and audio plugins nowadays use 64-bit floating point format for processing.

Only after all audio processing has been completed, the audio signal is dithered and then
truncated to 16 bits. And only if the audio is intended for an audio CD.

[Zbig]

But why you insist on that board?
For $31.50 you can have Teensy 4.1 ( https://www.pjrc.com/store/teensy41.html )
— clocked at 600 MHz and with ARM Cortex-M7. Still not powerful enough?
As I already wrote: boards featuring ESP32 are even much cheaper.

[Christopher Lozinski]

Lorum Ipsum wrote:
> Any musician is going to drop a 16 bit device in the trash, because the artifacts will be audible.

Thank you. I will drop music from the target market. Simplifies life.

But digital telephony is at 8 bits, so I should be able to do a hearing aid at 16 bits.

As for echo location, the number of bits is not nearly as important as the timing.

Why am I focused on small, low cost, efficient and many core?
This video from the recent open source conference will explain the issues with climate change, limits to growth and planetary boundaries.
https://peertube.f-si.org/videos/watch/73680ce5-dd9e-483c-b6dd-88abcda548c4
If you understand climate change,, you can skip to 26:30.
And of course FPGA's are just the first step.

I generally think of soft core processors on FPGA's as 10 times slower and 10 times larger than competing hard core cpus. If I have a 16bit soft core, it is half as wide, and half as tall, and so maybe 1/4 the size of a 32 bit soft core cpu, so it is only 2.5 times larger and slower than a 32 bit hard core cpu. Certainly levels the playing field a lot. A lot easier to be competitive in the market.

Why am I doing stack machines instead of register machines?
Register machines and C compilers are too complex for innovation. The Gnu C compiler is some 16 million lines of code. Impossible to innovate there. Stack machines allow me to do all kinds of interesting and needed things quite quickly and easily.

Why do I want more instructions? My instinct is that the additional 16 instructions that the Ting CPU provides would each take so many clock cycles to implement in the 16 instructions that the J1 provides, that although the ting cpu may half as fast, the application will run twice as fast. Supporting evidence is that the MicroCore with about 86 instructions, the author said he never needed a faster cpu.

Why do I use the term Forth processor? To distinguish it in my mind from a C processor.

> The dual port memory is internal to an FPGA and is available in nearly every device that is still in production.

Thank you. So I checked again. Turns out we both got it wrong. From the "iCE40 SPRAM Usage Guide"
The iCE40 devices offer four embedded memory blocks of SPRAM(Single Port RAM).... The iCE40 family has four 256 kb memory blocks available, that is a total of 1024 kb of Single Port memory. Each of these blocks can be configured only in 16K x 16 mode.

So the ICE40 family will not meet my needs for an audio processor. I will need to upgrade to the ECP5 boards. Tons of dual port memory, and more LUTs than I know what to do with. Great! Sadly not low power.

Warm Regards
Christopher Lozinski

[Zbig]

> Why am I focused on small, low cost, efficient and many core?
> This video from the recent open source conference will explain the issues with climate change, limits to growth and planetary boundaries.

Ah, so you're fighting the climate and planetary boundaries — and that requires multicore. :) Finally got it.

[Christopher Lozinski]

Not quite correct. I am mindful of the climate and planetary boundaries, and that tells me which direction the world is going.

My efforts to fight climate change are at the followinglink. You can watch 84 excellent videos about climate change, curated by numerous individuals.
https://uncensorednews.us/climate-change?query=&type=video&recommended=recommended&category=climate-change

The good news is that at least now people know that something is wrong with the climate. Generally, because of censorship, they still do not know how bad it already is, nor how much worse it is about to get.

Warm Regards
Christopher Lozinski

[Zbig]

Yeah, „all people contribute to climate change” (e.g. video #13) etc.
In fact YOU are the carbon they want to reduce. ;)

Warm(ing) Regards,
Z.

[Lorem Ipsum]

On Thursday, August 10, 2023 at 5:58:59 AM UTC-4, Christopher Lozinski wrote:
> Lorum Ipsum wrote:
> > Any musician is going to drop a 16 bit device in the trash, because the artifacts will be audible.
> Thank you. I will drop music from the target market. Simplifies life.
>
> But digital telephony is at 8 bits, so I should be able to do a hearing aid at 16 bits.
>
> As for echo location, the number of bits is not nearly as important as the timing.
>
> Why am I focused on small, low cost, efficient and many core?
> This video from the recent open source conference will explain the issues with climate change, limits to growth and planetary boundaries.
> https://peertube.f-si.org/videos/watch/73680ce5-dd9e-483c-b6dd-88abcda548c4
> If you understand climate change,, you can skip to 26:30.
> And of course FPGA's are just the first step.

"Climate change"??? Can't you just tell me what you are trying to do? At this point, I'm pretty confident you actually have no specific goals in mind and are just looking for a CPU idea to play with.

> I generally think of soft core processors on FPGA's as 10 times slower and 10 times larger than competing hard core cpus. If I have a 16bit soft core, it is half as wide, and half as tall, and so maybe 1/4 the size of a 32 bit soft core cpu, so it is only 2.5 times larger and slower than a 32 bit hard core cpu. Certainly levels the playing field a lot. A lot easier to be competitive in the market.

What market???

> Why am I doing stack machines instead of register machines?
> Register machines and C compilers are too complex for innovation. The Gnu C compiler is some 16 million lines of code. Impossible to innovate there. Stack machines allow me to do all kinds of interesting and needed things quite quickly and easily.

Stack processors are no more suited for innovation. There's nothing you can do with a stack machine that you can't do with a register machine. But you seem to be saying you think you can "innovate" with stack designs. Do you have any idea what these "innovations" would be???

> Why do I want more instructions? My instinct is that the additional 16 instructions that the Ting CPU provides would each take so many clock cycles to implement in the 16 instructions that the J1 provides, that although the ting cpu may half as fast, the application will run twice as fast. Supporting evidence is that the MicroCore with about 86 instructions, the author said he never needed a faster cpu.

I have to laugh at that a bit. I think this shows you are running with scissors. Rather than having a goal in mind, you want to design something that is "fast", without defining what "fast" means.

I've already explained that adding instructions can slow down the processor. You don't seem to have given that much attention.

> Why do I use the term Forth processor? To distinguish it in my mind from a C processor.

Forth doesn't specify a processor, other than the virtual machine. You could call it "Fred" and it would be distinguished from a register processor. To the best of my knowledge, there's no such thing as a C processor.

> > The dual port memory is internal to an FPGA and is available in nearly every device that is still in production.
> Thank you. So I checked again. Turns out we both got it wrong. From the "iCE40 SPRAM Usage Guide"
> The iCE40 devices offer four embedded memory blocks of SPRAM(Single Port RAM)....

Not sure what you are talking about here. Are you referring to the tiny memory in the 4 input LUTs? Actually, the iCE40 parts may not have those. The original designers of this line (the iCE65) removed a lot of functionality in their quest to reduce power.

> The iCE40 family has four 256 kb memory blocks available, that is a total of 1024 kb of Single Port memory. Each of these blocks can be configured only in 16K x 16 mode.

Every device I've looked at in the iCE40 families has multiple RAM blocks. Why do you say there are only four??? I think maybe you are looking at the SPRAM in the UltraPlus parts.

> So the ICE40 family will not meet my needs for an audio processor. I will need to upgrade to the ECP5 boards. Tons of dual port memory, and more LUTs than I know what to do with. Great! Sadly not low power.

Why the ECP5 parts? There are many FPGA providers. Have you looked at Gowin, Efinix, Xilinx(AMD), Altera(Intel)? Gowin and Efinix have good supply and prices.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

[SpainHackForth]

Well, since it was asked, here are three areas of possible innovation with a hardware dual-stack CPU (similar to Forth’s design) and their potential use cases:

- Real-time Systems and Embedded Applications:
**Innovation Area:
* Utilizing the dual-stack architecture for real-time systems and embedded applications can lead to precise and predictable execution of tasks, making it suitable for robotics, industrial automation, and control systems.
** Use Cases;
* Robotics Control- The architecture’s deterministic execution can ensure accurate control of robotic movements, enhancing safety and efficiency in tasks like manufacturing, assembly, and exploration.
* Industrial Automation- Dual-stack CPUs can power real-time automation systems, controlling processes with precise timing and responsiveness in industries such as manufacturing and logistics.
* IoT Devices- In IoT applications, the architecture can enable real-time monitoring and control of smart devices, ensuring rapid response to events and minimizing latency.
- Secure and Reliable Systems.
** Innovation Area:
* Leveraging the dual-stack architecture for secure and reliable systems can enhance software resilience, isolate critical components, and provide a strong foundation for secure computing environments.
** Use Cases:
* Cybersecurity: Dual-stack CPUs can facilitate secure booting, code integrity checks, and cryptographic operations. These features enhance system security, protect sensitive data, and defend against cyber threats.
* Safety-Critical Systems: The architecture’s isolation of control flow and data can be critical in safety-critical applications such as aerospace, automotive, and medical devices, minimizing the risk of software failures.
* Secure Transactions: For finncial and transactional systems, the dual-stack architecture can support secure execution of encryption algorithms and authentication protocols, safeguarding sensitive transactions.
- Advanced Algorithm Development.
** Innovation Area:
* The dual-stack architecture can inspire the development of novel algorithms and data structures that leverage the separation of data and control stacks, leading to improved computational efficiency and performance.
** Use Cases:
* Data Analytics: Developing algorithmsn for data processing, analysis, and transformation can benefit from the architecture’s ability to manage data separately from control flow, leading to optimized data-driven insights.
* Signal Processing: The architecture’s parallel processing capabilities can be harnessed for real-time signal processing tasks, such as audio and image processing, enabling faster and more accurate results.
*Scientific Computing: Dual-stack CPUs can accelerate complex scientific simulations by optimizing data manipulation and parallel computations, advancing research in various domains.

Personally, I believe that a hardware dual-stack CPU architecture, resembling Forth’s design, can drive many areas of innovation. The architecture’s predictable execution, separation of stacks, and parallel processing capabilities offer opportunities to create efficient and reliable solutions for various industries and applications.

Cheers and I look forward to positive contribution from all in the community.

JoseM

[Christopher Lozinski]

@SpainHackForth, thank you for the list of potential applications. Can you say more about this area which is of particular interest to me.

> Signal Processing: The architecture’s parallel processing capabilities can be harnessed for real-time signal processing tasks, such as audio and image processing, enabling faster and more accurate results.

@Lorum Ipsum

> Have you looked at Gowin, Efinix, Xilinx(AMD), Altera(Intel)? Gowin and Efinix have good supply and prices.

Thank you once again. No I have not, but I will.

As for all of your other questions, in due course they will be answered. For now you can think of me as a person playing with multiple Forth cores. And in particular Micromouse needs 4 * 24 bit Forth cores connected by 24 bit wires ending with 4 word FIFO's. That would make their development so much easier than developing on a not perfectly documented two core Microcontroller. In due course other innovations will also appear.

I still think that you are too goal oriented. What is the goal of a CPU? To run Linux? A many core Forth cpu can run many different applications. Slowly the range of applications are becoming more visible to me. As have the required customization. I believe I stated hearing aids, and echo location that are particularly interesting to me. Eventually vision, if I can find an FPGA with enough memory and reasonably priced. In particular assistance for the vision impaired.

> Yeah, „all people contribute to climate change”

Some contribute more than others.

"Top 1 Percent of Emitters Responsible for One Quarter of Emissions Since 1990"
https://e360.yale.edu/digest/carbon-emissions-inequality
"From 1990 to 2019, the bottom half of emitters was responsible for just 16 percent of emissions."

Warm Regards
Christopher Lozinski

[SpainHackForth]

On Thursday, August 10, 2023 at 5:56:48 PM UTC+2, Christopher Lozinski wrote:
> @SpainHackForth, thank you for the list of potential applications. Can you say more about this area which is of particular interest to me.
> > Signal Processing: The architecture’s parallel processing capabilities can be harnessed for real-time signal processing tasks, such as audio and image processing, enabling faster and more accurate results.

> Christopher Lozinski

Certainly, parallel processing is a powerful technique that involves performing multiple computational tasks simultaneously to achieve faster and more efficient data processing. In the context of signal processing, a dual-stack CPU architecture can leverage parallel processing to enhance the speed and accuracy of various signal analysis and manipulation tasks. These often involve applying the same operation to multiple data points or elements. With a dual-stack architecture, you can efficiently perform these operations in parallel by pushing the data onto the data stack and executing the operation concurrently for each element. This is particularly useful for tasks like applying filters, transformations, or mathematical operations to a large dataset.

This is also true for sequential operations. A dual-stack architecture can implement a pipeline structure, where each stage of the pipeline corresponds to a specific signal processing operation. The architecture can process multiple data elements simultaneously at different stages of the pipeline, increasing throughput.

Consider FFT and convolution, which are fundamental operations in signal processing. These operations can be highly parallelized using a dual-stack architecture. For example, a dual-stack CPU can split the input signal into multiple segments and perform FFT on each segment concurrently.

Fundamentally, I have been looking at Dual Stack CPU’s for some time now, trying to consider where the current needs for AI might apply, and I believe that there is a strong future and opportunities in this space, not as a means to win over a general purpose CPU, but on the contrary, be very diligent in specializing in a area of growth.

I have posted a longer conversation on this here… https://www.facebook.com/groups/1304548976637542/posts/1728121244280311/?comment_id=1728208484271587&reply_comment_id=1728259154266520&notif_id=1691601270071388&notif_t=group_comment_mention If you are interested in following that sort of topic.

Honestly, I initially approached stack CPUs and Forth FPGA implementations with skepticism, viewing them as technologies without clear objectives. However, after delving into the discussions, I’ve emerged more convinced than ever that when applied to specific use cases, these technologies hold significant potential and are worth leveraging.

[none albert]

In article <d617ced0-7d37-4967...@googlegroups.com>,

I have the suspicion that post was generated by AI.
The content is reminiscient of China's "People Review" in the 60's.
Basically devoid of content.

>
>JoseM
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

[SpainHackForth]

Was that intended as a compliment? Thank you!

By examining my other conversations, you'd notice my distinct approach: I often condense the dialogue, highlighting pertinent details that may otherwise be overlooked.

The terms I use offer a personal perspective on this specific architecture.

My emphasis has always been on the potential of AI in this architectural realm. Given the importance of data flow parallelization in computational pipelines, the movement of data is paramount. Most of my discourse revolves around this. However, to truly grasp the depth of my contribution, I'd suggest checking the provided link. This was my sincere effort to add value for the original poster.

[Myron Plichota]

You might be interested in the BugsBoard single-core implementation.

https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing

If you are, please email me one-on-one.

[S]

I probably posted the lightest boards around, and an alternative FPGA supplier with anti-fuse products as well. There was one little one that fits inside a USB slot. I can't remember other ones, but seed studio tries to do really small boards cheap, with heaps of prototyping/manufacture service for products and parts. Pretty, that word for forward thinking and covering basis. But, is there any fpga or other, I can run full steam at 1mw or less for ultra low power applications.

I think GA, is better off selling a more advanced low core large memory execute design to an FPGA manufacturer. Would hardly take up space or energy on most FPGAs, and a lot less than a soft cpu. But, I guess the b16 or J1 etc might do that. FPGA manufacturers probably would do a lot of funding for that, particularly something which offered C code acceleration, like Chuck's shboom did. Which you could also plug into circuits used for IO on Arm, which the FPGA manufacturers likely already has. I would just use the thing and turn the FPGA section off unless I wanted to use it. Low energy is a deficiency in FPGA they have a hard time competing with, mixed misc fpga parts where you can power down anything section not used, means they can do it all. I wonder why nobody put this together in the past. Misc is not competition to FPGA, but complimentary. 10,000 transistors for a CPU with basic control panel graphics, running at fractions or a mw 1Ghz (presuming with the low energy processes they have) it's virtually crazy not to.

Any of the record extra ultra low energy features that people have a problem with, can be replaced with faster simpler ultra low powered versions for no net penality on an constantly running performance system..