On 11/12/2021 01:24, Nickolay Kolchin wrote:
> On Saturday, December 11, 2021 at 2:03:34 AM UTC+3, gnuarm.del...@gmail.com wrote:
>> On Friday, December 10, 2021 at 2:49:54 PM UTC-5, Nickolay Kolchin wrote:
>>> On Friday, December 10, 2021 at 9:43:52 PM UTC+3, Paul Rubin wrote:
>>>> Rick C <gnuarm.del...@gmail.com> writes:
>>>> More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
>>>> perfectly useful and respectable. I've been programming those things a
>>>> little bit recently. But, they usually have 4K or more of program store
>>>> on the MCU. Having to use the GA144 ram as program memory (sharing it
>>>> with application data), or being limited to the 64 words (= 144 bytes)
>>>> of mask rom at each node, is horribly constricting, as the code on the
>>>> GA site shows. They had to do crazy things to make even simple programs
>>>> fit.
>>>>
>>> ATTiny make sense only in legacy applications. Cortex-M0 solutions are
>>> much more powerful at lesser price.
>> I have no idea why you say that. CM0 processors may be small and cheap, but basically just hold their own against 8 bit MCUs. Having more capability is only useful if you *have* a use for it. They still sell no small quantity of 4 bit MCUs, not because they are "legacy" applications, but because these parts are cheaper for the application.
>
> I don't follow you. Cortex-M0 have more I/O, more RAM, more Flash, more
> HZ, less power consumption and price starts from $0.35 at Digikey. There
> are zero reasons to choose 8-bit MCU unless:
>
> - You already have a board that needs small customisation.
> - You already have software for 8-bit
> - You know nothing about Cortex and don't want to learn.
>
> And 4-bit MCU are blast from past. I can't even imagine situation when this
> things may be used in new designs...
>
>>> Does GA144 have any practical usage beyond research papers? AFAIK, there
>>> are no commercial products based on GA144...
>> More importantly, it is hard to devise a practical application where a GA144 does the job in a better way than any other device. I'm not saying there are none, but they are few and far between and mostly not worth getting involved in the software for the GA144.
>
> About 5-7 years ago, we briefly considered GA144 for application that required
> extremely low power consumption. But programming looked too complex and
> the idea was ditched.
>
Hi Nickolay,

> But programming looked too complex and the idea was ditched.
Yes, it takes some time to get used to the arrayForth user interface :-)

Jeff Fox invented the "grey color token" in arrayForth to display
run-time data on the same screen as the pre-parsed source - I think of
this as Jeff's most important contribution to Computer Science.
I think this is a concept that only makes sense in the context of
arrayForth, so you have to get used to a life without files...

> About 5-7 years ago
At about that time I was looking at the possibility of using a GA144 to
simulate an 8051, to replace the Dallas/Maxim DS89C450 chip which was
becoming expensive.

The plan was to make a small PCB the size of a 40 pin DIP package, with
GA144, RTC, EEPROM and voltage level shifters - it was the voltage that
got me - every pin needed a buffer, and the cost and complexity became
too high.

This PCB would have run legacy 8051 code at maybe 100 MHz, consumed very
little current, and would have had the additional feature of maybe 120
spare F18 cores in case you need more processing power.

Even better would be the much hoped for (by me) improvement to the GA144
that allows each F18 core to pass data to its neighbors without
spinning. Apparently this is possible. This would reduce the power
consumption to close to the quiescent current, for example when waiting
for the user to press a key.

This would be very useful for extremely low power applications for the IoT.

I will ask Father Christmas for a GA144_b dev board using F18_b cores
with this new feature, and with 5V tolerant pins. I would be happy to
pay for the dev board (~$500), but unfortunately I lack the resources to
fund the development (~$10M) ;-)

Cheers,
Howerd

On 12/12/2021 15:33, Howerd Oakford wrote:
> On 10/12/2021 19:43, Paul Rubin wrote:
> ...
> > It also didn't help that the Polyforth VM that they include in the rom
> > on 3 the of the GA144 nodes is completely undocumented.
>
> Maybe you missed this :
> http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf
>
> I bought one of the GA development boards for around $500, and ran
> polyForth on it, so I can confirm that this is possible.
>
> polyForth ran surprisingly fast considering how little current it was
> using, and the impedence mis-match between the 18 bit GA144 and the 16
> bit polyForth VM.
>
> For me, this is pure experimental science and does not need to make
> money, although it would be nice if it did ;-)
>
> Times change, and the emphasis these days seems to be the IoT, where low
> power and small code size are becoming important again.
>
> The GA144 shows one way to design hardware and software to meet these
> kinds of constraints, so it may yet find a market...

But not if GA is so hard to program natively that one has to use PolyForth.
I suspect however porting PolyForth to the GA was little more than an
exercise. As for who is bankrolling GA, I wouldn't be surprised if it
were mainly Chuck. At his age, what's he got to lose. Same for 200x.

Howerd Oakford <howerd@inventio.co.uk> writes:
>> It also didn't help that the Polyforth VM that they include in the rom
>> on 3 the of the GA144 nodes is completely undocumented.
> Maybe you missed this :
> http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf

I did see that and want to get around to studying it someday, but unless
I missed something, that's the user manual for Polyforth itself. The
GA144 Polyforth implementation involves an interpreter running on a
virtual machine, that itself is implemented in F18a code written in
ArrayForth. That VM emulation code itself runs on three GA144 nodes and
the ArrayForth code is included in the blocks listing in some .html file
on the GA site someplace. It was generated by a Colorforth to HTML
converter. As with everything else in the GA144, they had to do
contorted and confusing things to fit it into the 64 available memory
words. That made it fairly hard to read.

I spent a few minutes looking at it and decided that really
understanding it and reverse engineering the VM instructions would take
considerable effort and I had other things to do, so I put it aside. I
do remember deciding that it didn't look that promising as a C compiler
target, but I wasn't certain of this. Maybe it could have been modified
to be a good target for both Polyforth and C though.

On Saturday, December 11, 2021 at 11:33:07 PM UTC-5, Howerd wrote:
>
> Times change, and the emphasis these days seems to be the IoT, where low
> power and small code size are becoming important again.
>
> The GA144 shows one way to design hardware and software to meet these
> kinds of constraints, so it may yet find a market...

The trouble is after all this time no such market has expressed an interest in what the GA144 has to offer. This is most likely because it is so hard to partition a design to spread across the 144 nodes. Heck, let's face it.. Even one processor at 700 MIPS and that power level would do nearly any IoT application if it had more memory than the 64 words in the F18A. One or another of the various limitations of this chip prevent it from being used in nearly every design out there.

--

Rick C.

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

On Sunday, December 12, 2021 at 12:09:11 AM UTC-5, Howerd wrote:
>
> At about that time I was looking at the possibility of using a GA144 to
> simulate an 8051, to replace the Dallas/Maxim DS89C450 chip which was
> becoming expensive.
>
> The plan was to make a small PCB the size of a 40 pin DIP package, with
> GA144, RTC, EEPROM and voltage level shifters - it was the voltage that
> got me - every pin needed a buffer, and the cost and complexity became
> too high.

That is a direct result of the GA144 not having an application in mind. A large fraction of the MCU chips on the market use 3.3 volt I/Os which are 5 volt tolerant. The rest still work at 3.3 volts. The GA144 is 100% 1.8 volts which requires level shifters. Pointing this out to the people at GA elicited the reply that transistors are cheap, meaning add transistors as level shifters. So you should add dozens of discrete transistors to save GA from having to provide 3.3 volt I/Os as the rest of the MCU world does.

> This PCB would have run legacy 8051 code at maybe 100 MHz, consumed very
> little current, and would have had the additional feature of maybe 120
> spare F18 cores in case you need more processing power.

Somebody makes a 100 MHz 8051. One of the intended uses is to emulate I/O functions (like UARTs) in interrupt driven code while the rest of the application runs in the background. Sound familiar?

> Even better would be the much hoped for (by me) improvement to the GA144
> that allows each F18 core to pass data to its neighbors without
> spinning. Apparently this is possible. This would reduce the power
> consumption to close to the quiescent current, for example when waiting
> for the user to press a key.

Spinning??? If you mean sitting in an idle loop of code, it already does that. One processor reads a port and the other processor writes the port. Which ever one is first waits for the other to act and then both can resume operation. There are no special instructions for this, it's part of the port operation.

> This would be very useful for extremely low power applications for the IoT.

Do you think?

> I will ask Father Christmas for a GA144_b dev board using F18_b cores
> with this new feature, and with 5V tolerant pins. I would be happy to
> pay for the dev board (~$500), but unfortunately I lack the resources to
> fund the development (~$10M) ;-)

3.3 volt maybe, but 5 volt I/Os are becoming less and less useful.

--

Rick C.

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

On Sunday, December 12, 2021 at 12:21:01 AM UTC-5, dxforth wrote:
> On 12/12/2021 15:33, Howerd Oakford wrote:
> > On 10/12/2021 19:43, Paul Rubin wrote:
> > ...
> > > It also didn't help that the Polyforth VM that they include in the rom
> > > on 3 the of the GA144 nodes is completely undocumented.
> >
> > Maybe you missed this :
> > http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf
> >
> > I bought one of the GA development boards for around $500, and ran
> > polyForth on it, so I can confirm that this is possible.
> >
> > polyForth ran surprisingly fast considering how little current it was
> > using, and the impedence mis-match between the 18 bit GA144 and the 16
> > bit polyForth VM.
> >
> > For me, this is pure experimental science and does not need to make
> > money, although it would be nice if it did ;-)
> >
> > Times change, and the emphasis these days seems to be the IoT, where low
> > power and small code size are becoming important again.
> >
> > The GA144 shows one way to design hardware and software to meet these
> > kinds of constraints, so it may yet find a market...
> But not if GA is so hard to program natively that one has to use PolyForth.
> I suspect however porting PolyForth to the GA was little more than an
> exercise. As for who is bankrolling GA, I wouldn't be surprised if it
> were mainly Chuck. At his age, what's he got to lose. Same for 200x.

I don't think that was the point of Polyforth. The idea is Polyforth gives you a conventional interface with a sizable memory as it uses an attached memory chip, no? You still need to write GA144 code for any specialized I/O functions which is one of the highly touted advantages of the GA144, so many processors you can use them to emulate I/O functions. That part of the GA144 makes perfect sense.

I never looked at the Polyforth for the GA144. I assume it includes words to access the comm ports of the three processors that make up the VM so that it can work with the rest of the CPUs on the chip.

--

Rick C.

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

Paul Rubin <no.email@nospam.invalid> writes:
>Its stacks as designed also
>live in block ram, but maybe LUTs could be used for them instead, as a
>LUT is basically a 16 bit RAM.

4 bit? And I don't think updates in non-programming mode are provided
for, are they?

>> (concerning the b16 name: Bernd Paysan... in a later presentation...
>> renamed the b16-dsp into b16-dsp, and the b16-small into b16).
>
>Oh I must not have seen the later one. The dsp name is interesting
>since iirc the first design didn't support multiplication, which on an
>fpga with dsp blocks is "free", so maybe there was a later redesign.

The b16s were designed for "real" hardware implementation, not FPGAs
(that's why the presentations talk about the size in some process, not
the LUTs), so there are no free multipliers to be had. The b16-dsp
has a multiply-step instruction *+ that the b16-small does not have.
The b16-dsp was designed for a car Hifi system.

>The b16-small was imho a little bit TOO small, and could have used
>another 1 or 2 stack levels to make programming a little easier.

You can fix this yourself.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>a LUT is basically a 16 bit RAM.
>
> 4 bit? And I don't think updates in non-programming mode are provided
> for, are they?

A LUT-4 has 4 input bits and 1 output bit, if I understand it right.
That lets it implement any 4-input logic function. Internally it is a
16 bit table.

I believe there is usually a way to use them as ram, for example as
1-bit registers, flip-flops, etc. Rick is the FPGA guy though. He
would know better than me. Actually IIRC, the b16 uses them for the top
two stack slots T and N, and b16-small uses them for T. I don't know
how that is done.

> The b16-dsp has a multiply-step instruction *+ that the b16-small does
> not have. The b16-dsp was designed for a car Hifi system.

Ah ok. I wonder if it is fast enough to implement the dsp functions
used in a hi-fi, such as audio equalization or antialiasing. I guess
probably.

On 12.12.2021 05:33, Howerd Oakford wrote:
> On 10/12/2021 19:43, Paul Rubin wrote:
> Hi Paul,
>
> > It also didn't help that the Polyforth VM that they include in the rom
> > on 3 the of the GA144 nodes is completely undocumented.
>
> Maybe you missed this :
> http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf

And, still more important for the GA144 polyFORTH implementation, the
polyForth supplement platform document:

http://www.greenarraychips.com/home/documents/greg/DB006-200126-PF-G144A12.pdf

>
> I bought one of the GA development boards for around $500, and ran
> polyForth on it, so I can confirm that this is possible.
>
> polyForth ran surprisingly fast considering how little current it was
> using, and the impedence mis-match between the 18 bit GA144 and the 16
> bit polyForth VM.
>
> For me, this is pure experimental science and does not need to make
> money, although it would be nice if it did ;-)
>
> Times change, and the emphasis these days seems to be the IoT, where low
> power and small code size are becoming important again.
>
> The GA144 shows one way to design hardware and software to meet these
> kinds of constraints, so it may yet find a market...

--
Bernd

On 12/12/2021 07:37, Paul Rubin wrote:
> Howerd Oakford <howerd@inventio.co.uk> writes:
>>> It also didn't help that the Polyforth VM that they include in the rom
>>> on 3 the of the GA144 nodes is completely undocumented.
>> Maybe you missed this :
>> http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf
>
> I did see that and want to get around to studying it someday, but unless
> I missed something, that's the user manual for Polyforth itself. The
> GA144 Polyforth implementation involves an interpreter running on a
> virtual machine, that itself is implemented in F18a code written in
> ArrayForth. That VM emulation code itself runs on three GA144 nodes and
> the ArrayForth code is included in the blocks listing in some .html file
> on the GA site someplace. It was generated by a Colorforth to HTML
> converter. As with everything else in the GA144, they had to do
> contorted and confusing things to fit it into the 64 available memory
> words. That made it fairly hard to read.
>
> I spent a few minutes looking at it and decided that really
> understanding it and reverse engineering the VM instructions would take
> considerable effort and I had other things to do, so I put it aside. I
> do remember deciding that it didn't look that promising as a C compiler
> target, but I wasn't certain of this. Maybe it could have been modified
> to be a good target for both Polyforth and C though.
Hi Paul,

My bad - I misunderstood your comment.
And I agree with you that the route between the GA144 and the rest of
the world is contorted - HTML etc.

Cheers,
Howerd

On 12/12/2021 07:51, Rick C wrote:
> On Sunday, December 12, 2021 at 12:09:11 AM UTC-5, Howerd wrote:
>>
>> At about that time I was looking at the possibility of using a GA144 to
>> simulate an 8051, to replace the Dallas/Maxim DS89C450 chip which was
>> becoming expensive.
>>
>> The plan was to make a small PCB the size of a 40 pin DIP package, with
>> GA144, RTC, EEPROM and voltage level shifters - it was the voltage that
>> got me - every pin needed a buffer, and the cost and complexity became
>> too high.
>
> That is a direct result of the GA144 not having an application in mind. A large fraction of the MCU chips on the market use 3.3 volt I/Os which are 5 volt tolerant. The rest still work at 3.3 volts. The GA144 is 100% 1.8 volts which requires level shifters. Pointing this out to the people at GA elicited the reply that transistors are cheap, meaning add transistors as level shifters. So you should add dozens of discrete transistors to save GA from having to provide 3.3 volt I/Os as the rest of the MCU world does.
>
>
>> This PCB would have run legacy 8051 code at maybe 100 MHz, consumed very
>> little current, and would have had the additional feature of maybe 120
>> spare F18 cores in case you need more processing power.
>
> Somebody makes a 100 MHz 8051. One of the intended uses is to emulate I/O functions (like UARTs) in interrupt driven code while the rest of the application runs in the background. Sound familiar?
>
>
>> Even better would be the much hoped for (by me) improvement to the GA144
>> that allows each F18 core to pass data to its neighbors without
>> spinning. Apparently this is possible. This would reduce the power
>> consumption to close to the quiescent current, for example when waiting
>> for the user to press a key.
>
> Spinning??? If you mean sitting in an idle loop of code, it already does that. One processor reads a port and the other processor writes the port. Which ever one is first waits for the other to act and then both can resume operation. There are no special instructions for this, it's part of the port operation.
>
>
>> This would be very useful for extremely low power applications for the IoT.
>
> Do you think?
>
>
>> I will ask Father Christmas for a GA144_b dev board using F18_b cores
>> with this new feature, and with 5V tolerant pins. I would be happy to
>> pay for the dev board (~$500), but unfortunately I lack the resources to
>> fund the development (~$10M) ;-)
>
> 3.3 volt maybe, but 5 volt I/Os are becoming less and less useful.
>
Hi Rick,

> That is a direct result of the GA144 not having an application in
> mind.
Agreed. They were trying to woo the world with speed, calculated as the
speed of one F18 multiplied by 144. As you know the real world it a lot
more complicate than that ;-)

> So you should add dozens of discrete transistors to save GA from
> having to provide 3.3 volt I/Os as the rest of the MCU world does.
IIRC 32 pins, meaning four 8 way level shifters. This made the PCB vary
packed, and hiked the cost up...

>> This would be very useful for extremely low power applications
>> for the IoT.
> Do you think?
Yes - if you have the minimum hardware doing the minimum number of state
changes it will use the mimimum power, and you can't get better than that.

Cheers,
Howerd

On Sunday, December 12, 2021 at 8:09:11 AM UTC+3, Howerd wrote:
> On 11/12/2021 01:24, Nickolay Kolchin wrote:
> > On Saturday, December 11, 2021 at 2:03:34 AM UTC+3, gnuarm.del...@gmail..com wrote:
> >> On Friday, December 10, 2021 at 2:49:54 PM UTC-5, Nickolay Kolchin wrote:
> >>> On Friday, December 10, 2021 at 9:43:52 PM UTC+3, Paul Rubin wrote:
> >>>> Rick C <gnuarm.del...@gmail.com> writes:
> >>>> More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> >>>> perfectly useful and respectable. I've been programming those things a
> >>>> little bit recently. But, they usually have 4K or more of program store
> >>>> on the MCU. Having to use the GA144 ram as program memory (sharing it
> >>>> with application data), or being limited to the 64 words (= 144 bytes)
> >>>> of mask rom at each node, is horribly constricting, as the code on the
> >>>> GA site shows. They had to do crazy things to make even simple programs
> >>>> fit.
> >>>>
> >>> ATTiny make sense only in legacy applications. Cortex-M0 solutions are
> >>> much more powerful at lesser price.
> >> I have no idea why you say that. CM0 processors may be small and cheap, but basically just hold their own against 8 bit MCUs. Having more capability is only useful if you *have* a use for it. They still sell no small quantity of 4 bit MCUs, not because they are "legacy" applications, but because these parts are cheaper for the application.
> >
> > I don't follow you. Cortex-M0 have more I/O, more RAM, more Flash, more
> > HZ, less power consumption and price starts from $0.35 at Digikey. There
> > are zero reasons to choose 8-bit MCU unless:
> >
> > - You already have a board that needs small customisation.
> > - You already have software for 8-bit
> > - You know nothing about Cortex and don't want to learn.
> >
> > And 4-bit MCU are blast from past. I can't even imagine situation when this
> > things may be used in new designs...
> >
> >>> Does GA144 have any practical usage beyond research papers? AFAIK, there
> >>> are no commercial products based on GA144...
> >> More importantly, it is hard to devise a practical application where a GA144 does the job in a better way than any other device. I'm not saying there are none, but they are few and far between and mostly not worth getting involved in the software for the GA144.
> >
> > About 5-7 years ago, we briefly considered GA144 for application that required
> > extremely low power consumption. But programming looked too complex and
> > the idea was ditched.
> >
> Hi Nickolay,
> > But programming looked too complex and the idea was ditched.
> Yes, it takes some time to get used to the arrayForth user interface :-)
>
> Jeff Fox invented the "grey color token" in arrayForth to display
> run-time data on the same screen as the pre-parsed source - I think of
> this as Jeff's most important contribution to Computer Science.
> I think this is a concept that only makes sense in the context of
> arrayForth, so you have to get used to a life without files...
>
> > About 5-7 years ago
> At about that time I was looking at the possibility of using a GA144 to
> simulate an 8051, to replace the Dallas/Maxim DS89C450 chip which was
> becoming expensive.
>
> The plan was to make a small PCB the size of a 40 pin DIP package, with
> GA144, RTC, EEPROM and voltage level shifters - it was the voltage that
> got me - every pin needed a buffer, and the cost and complexity became
> too high.
>
> This PCB would have run legacy 8051 code at maybe 100 MHz, consumed very
> little current, and would have had the additional feature of maybe 120
> spare F18 cores in case you need more processing power.
>

https://www.dcd.pl/product/dp8051/ -- Doesn't this fit your needs?

On Sunday, December 12, 2021 at 12:42:13 AM UTC+3, Paul Rubin wrote:
>
> The 1616 is available in a 20 pin, 3mm*3mm VQFN package. That is
> important for this application. I don't know of any comparable ARM part
> available in such a small package that is not WLCSP, which is far harder
> to work with. I'd be interested if you know of something.

Maxim has MAX32660 series with TQFN, but they cost about $1.5.

Also Gigadevices has GD32E230 with QFN. Not sure about price though.

Bernd Linsel <bl1-removethis@gmx.com> writes:
> And, still more important for the GA144 polyFORTH implementation, the
> polyForth supplement platform document:
>
> http://www.greenarraychips.com/home/documents/greg/DB006-200126-PF-G144A12.pdf

Thanks! I don't remember seeing this before. It looks helpful. It
also shows what a pain it is to program the GA144, because of the
limited memory and connectivity at the nodes.

Nickolay Kolchin <nbkolchin@gmail.com> writes:
> Maxim has MAX32660 series with TQFN, but they cost about $1.5.
> Also Gigadevices has GD32E230 with QFN. Not sure about price though.

Wow, thanks! The $1.5 is probably tolerable. I will check the analog
and related capabilities, which also matter.

https://www.maximintegrated.com/en/products/microcontrollers/MAX32660.html
https://www.gigadevice.com/products/microcontrollers/gd32/arm-cortex-m23/value-line/gd32e230-series/

I wonder if GD will make a RISC-V version of the GD32E230.

On Sunday, December 12, 2021 at 11:09:09 AM UTC-5, Howerd wrote:
> On 12/12/2021 07:51, Rick C wrote:
> > On Sunday, December 12, 2021 at 12:09:11 AM UTC-5, Howerd wrote:
> >>
> >> At about that time I was looking at the possibility of using a GA144 to
> >> simulate an 8051, to replace the Dallas/Maxim DS89C450 chip which was
> >> becoming expensive.
> >>
> >> The plan was to make a small PCB the size of a 40 pin DIP package, with
> >> GA144, RTC, EEPROM and voltage level shifters - it was the voltage that
> >> got me - every pin needed a buffer, and the cost and complexity became
> >> too high.
> >
> > That is a direct result of the GA144 not having an application in mind. A large fraction of the MCU chips on the market use 3.3 volt I/Os which are 5 volt tolerant. The rest still work at 3.3 volts. The GA144 is 100% 1.8 volts which requires level shifters. Pointing this out to the people at GA elicited the reply that transistors are cheap, meaning add transistors as level shifters. So you should add dozens of discrete transistors to save GA from having to provide 3.3 volt I/Os as the rest of the MCU world does.
> >
> >
> >> This PCB would have run legacy 8051 code at maybe 100 MHz, consumed very
> >> little current, and would have had the additional feature of maybe 120
> >> spare F18 cores in case you need more processing power.
> >
> > Somebody makes a 100 MHz 8051. One of the intended uses is to emulate I/O functions (like UARTs) in interrupt driven code while the rest of the application runs in the background. Sound familiar?
> >
> >
> >> Even better would be the much hoped for (by me) improvement to the GA144
> >> that allows each F18 core to pass data to its neighbors without
> >> spinning. Apparently this is possible. This would reduce the power
> >> consumption to close to the quiescent current, for example when waiting
> >> for the user to press a key.
> >
> > Spinning??? If you mean sitting in an idle loop of code, it already does that. One processor reads a port and the other processor writes the port. Which ever one is first waits for the other to act and then both can resume operation. There are no special instructions for this, it's part of the port operation.
> >
> >
> >> This would be very useful for extremely low power applications for the IoT.
> >
> > Do you think?
> >
> >
> >> I will ask Father Christmas for a GA144_b dev board using F18_b cores
> >> with this new feature, and with 5V tolerant pins. I would be happy to
> >> pay for the dev board (~$500), but unfortunately I lack the resources to
> >> fund the development (~$10M) ;-)
> >
> > 3.3 volt maybe, but 5 volt I/Os are becoming less and less useful.
> >
> Hi Rick,
> > That is a direct result of the GA144 not having an application in
> > mind.
> Agreed. They were trying to woo the world with speed, calculated as the
> speed of one F18 multiplied by 144. As you know the real world it a lot
> more complicate than that ;-)
> > So you should add dozens of discrete transistors to save GA from
> > having to provide 3.3 volt I/Os as the rest of the MCU world does.
> IIRC 32 pins, meaning four 8 way level shifters. This made the PCB vary
> packed, and hiked the cost up...
> >> This would be very useful for extremely low power applications
> >> for the IoT.
> > Do you think?
> Yes - if you have the minimum hardware doing the minimum number of state
> changes it will use the mimimum power, and you can't get better than that..

I'm not sure the analogy holds. There is a coefficient for the power used by each CPU and while the F18A may have a lower coefficient, it is not a very complete architecture. One point that is often overlooked or even touted as an advantage when it is actually not, is the asynchronous nature of the CPUs. While it sounds good in theory, there are relatively few applications where you don't need to synchronize to a clock to do the job, either via comms to another device or by establishing timing for many different reasons. The GA144 has no clock, so you have to design one into your code. Then the entire machine is once again synchronous running operations on every transition of the clock.

A perfect example is the ADC. It requires a free running oscillator and counter that consume significant current. Then you need a sampling clock which triggers a node to take samples of the counter on a regular basis using even more power.

We can talk about the GA144 being power efficient in theory, but until the device is used in an application the theoretical power level doesn't mean a thing.

Do you have any IoT applications in mind? Which ones would the GA144 be good at?

--

Rick C.

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

Concerning theoretical markets. Why don't people do misc, the way they want. Open Misc. You know of a couple of different avenues to get it made, France and Google. Make IoT, MCU and high performance. GA might even get on board in years to come.

On Monday, 13 December 2021 at 06:01:21 UTC, Wayne morellini wrote:
> Concerning theoretical markets. Why don't people do misc, the way they want. Open Misc. You know of a couple of different avenues to get it made, France and Google. Make IoT, MCU and high performance. GA might even get on board in years to come.

There is one commercial aspect that I think has not been mentioned but would be crucial for many companies:

Which company will take such a risk of designing in a processor,
that has not been updated for the last how many years?
5?
10?

And who could second source the GA144, if GA decides to stop the product?

The updated version of the GA144 is on the GA website
with no expected date of availability or a preliminary data sheet.

And all of these points are completely independent of markets and applications.

For me this GA144 was a test for Chuck's design system.
Brilliant design and independent of commercial CAD software.

Who else has achieved this?
Design and have manufactured a working multiprocessor and do the related software.

On Monday, December 13, 2021 at 8:24:39 AM UTC-7, jpit...@gmail.com wrote:
> For me this GA144 was a test for Chuck's design system.
> Brilliant design and independent of commercial CAD software.
>
> Who else has achieved this?
> Design and have manufactured a working multiprocessor and do the related software.

John Hart did this with the MiniForth processor in 1994 --- and, unlike the GA144,
the MiniForth had a practical application (the laser-etcher machine) --- also, unlike the GA144,
the MiniForth was tightly-coupled parallelism rather than loosely-coupled parallelism.

John Hart is gone now --- most likely riding his pro-life hobby-horse at a gallop towards his own death.
Now we have Tom Hart impersonating John Hart using a fake gmail address --- grossly disrespectful!
The MiniForth was pretty cool in its day (late 1990s), but that day has passed.

On Tuesday, 14 December 2021 at 01:40:00 UTC, Hugh Aguilar wrote:
> On Monday, December 13, 2021 at 8:24:39 AM UTC-7, jpit...@gmail.com wrote:
> > For me this GA144 was a test for Chuck's design system.
> > Brilliant design and independent of commercial CAD software.
> >
> > Who else has achieved this?
> > Design and have manufactured a working multiprocessor and do the related software.
> John Hart did this with the MiniForth processor in 1994 --- and, unlike the GA144,
> the MiniForth had a practical application (the laser-etcher machine) --- also, unlike the GA144,
> the MiniForth was tightly-coupled parallelism rather than loosely-coupled parallelism.
>
> John Hart is gone now --- most likely riding his pro-life hobby-horse at a gallop towards his own death.
> Now we have Tom Hart impersonating John Hart using a fake gmail address --- grossly disrespectful!
> The MiniForth was pretty cool in its day (late 1990s), but that day has passed.

Typical Hugh Aguilar BULLSHIT again.

He does not have a clue about the subject.
With GA144 we are talking about silicon design - not writing code for an FPGA / CPLD..

Anybody can use an FPGA as a basis. And have a CPU even.

I convinced my colleagues in 1997 to write a little CPU for a a Lattice CPLD
- it was a nice running demo at exhibitions.

The design made it via FH Nuremberg into a student's final work
- and was then manufactured at AMS into silicon.

So, in this project there were both aspects.

jpit...@gmail.com schrieb am Dienstag, 14. Dezember 2021 um 08:37:52 UTC+1:
> On Tuesday, 14 December 2021 at 01:40:00 UTC, Hugh Aguilar wrote:
> > On Monday, December 13, 2021 at 8:24:39 AM UTC-7, jpit...@gmail.com wrote:
> > > For me this GA144 was a test for Chuck's design system.
> > > Brilliant design and independent of commercial CAD software.
> > >
> > > Who else has achieved this?
> > > Design and have manufactured a working multiprocessor and do the related software.
> > John Hart did this with the MiniForth processor in 1994 --- and, unlike the GA144,
> > the MiniForth had a practical application (the laser-etcher machine) --- also, unlike the GA144,
> > the MiniForth was tightly-coupled parallelism rather than loosely-coupled parallelism.
> >
> > John Hart is gone now --- most likely riding his pro-life hobby-horse at a gallop towards his own death.
> > Now we have Tom Hart impersonating John Hart using a fake gmail address --- grossly disrespectful!
> > The MiniForth was pretty cool in its day (late 1990s), but that day has passed.
> Typical Hugh Aguilar BULLSHIT again.
>
> He does not have a clue about the subject.
> With GA144 we are talking about silicon design - not writing code for an FPGA / CPLD..
>
> Anybody can use an FPGA as a basis. And have a CPU even.
>
> I convinced my colleagues in 1997 to write a little CPU for a a Lattice CPLD
> - it was a nice running demo at exhibitions.
>
> The design made it via FH Nuremberg into a student's final work
> - and was then manufactured at AMS into silicon.
>
> So, in this project there were both aspects.

FWIW example code for an FPGA CPU:
https://github.com/Arlet/verilog-65c02

Although I rather doubt it would run well at 6 GHz! ;-)
(high frequency electronics can cause you sleepless nights...)

That said I have great respect for CPU design for those
frequencies. I guess one has to spend more time on thermal
cooling design and wire length optimization than on the 'naked' CPU.

On 12/12/2021 17:32, Nickolay Kolchin wrote:
> On Sunday, December 12, 2021 at 8:09:11 AM UTC+3, Howerd wrote:
>> On 11/12/2021 01:24, Nickolay Kolchin wrote:
>>> On Saturday, December 11, 2021 at 2:03:34 AM UTC+3, gnuarm.del...@gmail.com wrote:
>>>> On Friday, December 10, 2021 at 2:49:54 PM UTC-5, Nickolay Kolchin wrote:
>>>>> On Friday, December 10, 2021 at 9:43:52 PM UTC+3, Paul Rubin wrote:
>>>>>> Rick C <gnuarm.del...@gmail.com> writes:
>>>>>> More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
>>>>>> perfectly useful and respectable. I've been programming those things a
>>>>>> little bit recently. But, they usually have 4K or more of program store
>>>>>> on the MCU. Having to use the GA144 ram as program memory (sharing it
>>>>>> with application data), or being limited to the 64 words (= 144 bytes)
>>>>>> of mask rom at each node, is horribly constricting, as the code on the
>>>>>> GA site shows. They had to do crazy things to make even simple programs
>>>>>> fit.
>>>>>>
>>>>> ATTiny make sense only in legacy applications. Cortex-M0 solutions are
>>>>> much more powerful at lesser price.
>>>> I have no idea why you say that. CM0 processors may be small and cheap, but basically just hold their own against 8 bit MCUs. Having more capability is only useful if you *have* a use for it. They still sell no small quantity of 4 bit MCUs, not because they are "legacy" applications, but because these parts are cheaper for the application.
>>>
>>> I don't follow you. Cortex-M0 have more I/O, more RAM, more Flash, more
>>> HZ, less power consumption and price starts from $0.35 at Digikey. There
>>> are zero reasons to choose 8-bit MCU unless:
>>>
>>> - You already have a board that needs small customisation.
>>> - You already have software for 8-bit
>>> - You know nothing about Cortex and don't want to learn.
>>>
>>> And 4-bit MCU are blast from past. I can't even imagine situation when this
>>> things may be used in new designs...
>>>
>>>>> Does GA144 have any practical usage beyond research papers? AFAIK, there
>>>>> are no commercial products based on GA144...
>>>> More importantly, it is hard to devise a practical application where a GA144 does the job in a better way than any other device. I'm not saying there are none, but they are few and far between and mostly not worth getting involved in the software for the GA144.
>>>
>>> About 5-7 years ago, we briefly considered GA144 for application that required
>>> extremely low power consumption. But programming looked too complex and
>>> the idea was ditched.
>>>
>> Hi Nickolay,
>>> But programming looked too complex and the idea was ditched.
>> Yes, it takes some time to get used to the arrayForth user interface :-)
>>
>> Jeff Fox invented the "grey color token" in arrayForth to display
>> run-time data on the same screen as the pre-parsed source - I think of
>> this as Jeff's most important contribution to Computer Science.
>> I think this is a concept that only makes sense in the context of
>> arrayForth, so you have to get used to a life without files...
>>
>>> About 5-7 years ago
>> At about that time I was looking at the possibility of using a GA144 to
>> simulate an 8051, to replace the Dallas/Maxim DS89C450 chip which was
>> becoming expensive.
>>
>> The plan was to make a small PCB the size of a 40 pin DIP package, with
>> GA144, RTC, EEPROM and voltage level shifters - it was the voltage that
>> got me - every pin needed a buffer, and the cost and complexity became
>> too high.
>>
>> This PCB would have run legacy 8051 code at maybe 100 MHz, consumed very
>> little current, and would have had the additional feature of maybe 120
>> spare F18 cores in case you need more processing power.
>>
>
> https://www.dcd.pl/product/dp8051/ -- Doesn't this fit your needs?
>
>
Hi Nickolay,

From their website : "Based in Poland, European Union, our company
provides Verilog and VHDL"

I wasn't planning on making my own chips ;-)

Cheers,
Howerd

On Tuesday, December 14, 2021 at 4:07:39 PM UTC+3, Howerd wrote:
> On 12/12/2021 17:32, Nickolay Kolchin wrote:
> > On Sunday, December 12, 2021 at 8:09:11 AM UTC+3, Howerd wrote:
> >> On 11/12/2021 01:24, Nickolay Kolchin wrote:
> >>> On Saturday, December 11, 2021 at 2:03:34 AM UTC+3, gnuarm.del...@gmail.com wrote:
> >>>> On Friday, December 10, 2021 at 2:49:54 PM UTC-5, Nickolay Kolchin wrote:
> >>>>> On Friday, December 10, 2021 at 9:43:52 PM UTC+3, Paul Rubin wrote:
> >>>>>> Rick C <gnuarm.del...@gmail.com> writes:
> >>>>>> More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> >>>>>> perfectly useful and respectable. I've been programming those things a
> >>>>>> little bit recently. But, they usually have 4K or more of program store
> >>>>>> on the MCU. Having to use the GA144 ram as program memory (sharing it
> >>>>>> with application data), or being limited to the 64 words (= 144 bytes)
> >>>>>> of mask rom at each node, is horribly constricting, as the code on the
> >>>>>> GA site shows. They had to do crazy things to make even simple programs
> >>>>>> fit.
> >>>>>>
> >>>>> ATTiny make sense only in legacy applications. Cortex-M0 solutions are
> >>>>> much more powerful at lesser price.
> >>>> I have no idea why you say that. CM0 processors may be small and cheap, but basically just hold their own against 8 bit MCUs. Having more capability is only useful if you *have* a use for it. They still sell no small quantity of 4 bit MCUs, not because they are "legacy" applications, but because these parts are cheaper for the application.
> >>>
> >>> I don't follow you. Cortex-M0 have more I/O, more RAM, more Flash, more
> >>> HZ, less power consumption and price starts from $0.35 at Digikey. There
> >>> are zero reasons to choose 8-bit MCU unless:
> >>>
> >>> - You already have a board that needs small customisation.
> >>> - You already have software for 8-bit
> >>> - You know nothing about Cortex and don't want to learn.
> >>>
> >>> And 4-bit MCU are blast from past. I can't even imagine situation when this
> >>> things may be used in new designs...
> >>>
> >>>>> Does GA144 have any practical usage beyond research papers? AFAIK, there
> >>>>> are no commercial products based on GA144...
> >>>> More importantly, it is hard to devise a practical application where a GA144 does the job in a better way than any other device. I'm not saying there are none, but they are few and far between and mostly not worth getting involved in the software for the GA144.
> >>>
> >>> About 5-7 years ago, we briefly considered GA144 for application that required
> >>> extremely low power consumption. But programming looked too complex and
> >>> the idea was ditched.
> >>>
> >> Hi Nickolay,
> >>> But programming looked too complex and the idea was ditched.
> >> Yes, it takes some time to get used to the arrayForth user interface :-)
> >>
> >> Jeff Fox invented the "grey color token" in arrayForth to display
> >> run-time data on the same screen as the pre-parsed source - I think of
> >> this as Jeff's most important contribution to Computer Science.
> >> I think this is a concept that only makes sense in the context of
> >> arrayForth, so you have to get used to a life without files...
> >>
> >>> About 5-7 years ago
> >> At about that time I was looking at the possibility of using a GA144 to
> >> simulate an 8051, to replace the Dallas/Maxim DS89C450 chip which was
> >> becoming expensive.
> >>
> >> The plan was to make a small PCB the size of a 40 pin DIP package, with
> >> GA144, RTC, EEPROM and voltage level shifters - it was the voltage that
> >> got me - every pin needed a buffer, and the cost and complexity became
> >> too high.
> >>
> >> This PCB would have run legacy 8051 code at maybe 100 MHz, consumed very
> >> little current, and would have had the additional feature of maybe 120
> >> spare F18 cores in case you need more processing power.
> >>
> >
> > https://www.dcd.pl/product/dp8051/ -- Doesn't this fit your needs?
> >
> >
> Hi Nickolay,
>
> From their website : "Based in Poland, European Union, our company
> provides Verilog and VHDL"
>
> I wasn't planning on making my own chips ;-)
>

They are available for FPGA.

I thought I replied to this sorry.

On Tuesday, December 14, 2021 at 1:24:39 AM UTC+10, jpit...@gmail.com wrote:
> On Monday, 13 December 2021 at 06:01:21 UTC, Wayne morellini wrote:
> > Concerning theoretical markets. Why don't people do misc, the way they want. Open Misc. You know of a couple of different avenues to get it made, France and Google. Make IoT, MCU and high performance. GA might even get on board in years to come.
> There is one commercial aspect that I think has not been mentioned but would be crucial for many companies:
>
> Which company will take such a risk of designing in a processor,
> that has not been updated for the last how many years?
> 5?
> 10?
>
> And who could second source the GA144, if GA decides to stop the product?
>
> The updated version of the GA144 is on the GA website
> with no expected date of availability or a preliminary data sheet.
>
> And all of these points are completely independent of markets and applications.
>
> For me this GA144 was a test for Chuck's design system.
> Brilliant design and independent of commercial CAD software.
>
> Who else has achieved this?
> Design and have manufactured a working multiprocessor and do the related software.

What's your name?

That doesn't make sense. We are not talking about designing an ga144, but a brand new misc processor, with whatever architecture you like in it. GA could contribute one day, but again, even if they did, that doesn't need to be the ga144, though a redesigned ga144 would be useful in the lowest category. Something that hadn't been upgraded is a target for upgrade. You'll not get places denying and stopping everything.

I think there is a fundamental misunderstanding of what the current generation of misc was meant to be, and that's why it's doesn't seem to fit other things. All this discussion of planning a product for a general purpose CPU is misguided. Sure you need to fit a integrated category these days (even as a plain microcontroller, low component implementation with the right software and ports, is an integration category), but the CPU needs to be applicable generally to a wide range of programming past that. GA is changeable in those ways, along the lines I have written, and while it might still not be the broadest design, it would still be sellable in some areas. People here hassle about killing GA chips, instead of seeing a way out the forest.

Now, as for a lowest end product, 8 bit or 16 bit, is just as doable as 18 bit (4 or 8 bit versions of the 18, with instruction, addressability and data flow enhancements, as I've discussed). I'd be interested to know about these Chinese 4 bit design and, to see how they line up with my 4 and 2 bit architecture proposals.

Say, as a consumer market strategy, the x18 category would be suitable for a product in the lowest end phone category, raising it up a level with JavaScript support. A general MCU could be a subset of that. The issue here, is not the rest of the chip, but integration of 4G/5G modem which is real complexity and licensing. That potentially.wpuld be more costly then the rest of the design, unless there is a low cost cell design licence out of the IOT domain, when vh desires 5G/6G comms.

On Tuesday, December 14, 2021 at 5:37:52 PM UTC+10, jpit...@gmail.com wrote:
> On Tuesday, 14 December 2021 at 01:40:00 UTC, Hugh Aguilar wrote:
> > On Monday, December 13, 2021 at 8:24:39 AM UTC-7, jpit...@gmail.com wrote:
> > > For me this GA144 was a test for Chuck's design system.
> > > Brilliant design and independent of commercial CAD software.
> > >
> > > Who else has achieved this?
> > > Design and have manufactured a working multiprocessor and do the related software.
> > John Hart did this with the MiniForth processor in 1994 --- and, unlike the GA144,
> > the MiniForth had a practical application (the laser-etcher machine) --- also, unlike the GA144,
> > the MiniForth was tightly-coupled parallelism rather than loosely-coupled parallelism.
> >
> > John Hart is gone now --- most likely riding his pro-life hobby-horse at a gallop towards his own death.
> > Now we have Tom Hart impersonating John Hart using a fake gmail address --- grossly disrespectful!
> > The MiniForth was pretty cool in its day (late 1990s), but that day has passed.
> Typical Hugh Aguilar BULLSHIT again.
>
> He does not have a clue about the subject.
> With GA144 we are talking about silicon design - not writing code for an FPGA / CPLD..
>
> Anybody can use an FPGA as a basis. And have a CPU even.
>
> I convinced my colleagues in 1997 to write a little CPU for a a Lattice CPLD
> - it was a nice running demo at exhibitions.
>
> The design made it via FH Nuremberg into a student's final work
> - and was then manufactured at AMS into silicon.
>
> So, in this project there were both aspects.

Which processor was that?

Now, why pick on High? Let him live out past glories and what happened. You filling up the place with negative rubbish. He's been done wrong, you having a go at home is not going make it better. Time dims the memory and skills, but he could be designing open misc FPGA (with the licensed excluding certain people from using it), or some other useful thing around here in his spare are time. There are a lot of people hanging around here doing nothing, who could do something constructive. Work with mindfkex, work on forth os, work on a forth editor or development system, work on base application frame works, services, integration with common hardware or software, such as using common embedded systems and interfaces, the Linux universal driver system,window and Mac driver system. Os boot systems for PC. Somebody has to make the infrastructure for the next generation to pick up and succeed. I had planned on making an alternative to Forth. And misc, but got too sick. Now. I can't do what is used to by far. I just went to the kitchen filled the jug and put it in the wrong place, even though I can still debate people. To me, forth is what's inside the jug unit now, and though I can still do architecture, the details are more hidden than before, and my design more linear, but I still remember some of the old stuff. I've gone from an Steve Wozniak to a Steve Jobs in some of that. However, I had previously identified that forth and misc were lacking, and there is still a lot of gain the community could design in. We all getting old, what are we going leave behind. Because, after we go, is forth going die? It needs an open source effort, to make it a mainstream alternative. I am also taking about modelling the best instruction type and flow, and make a simpler forth with libraries, to do big things, in a simpler version than ANS. (This is ironically going in a direction which sounds like a misc spirited forth). The two aims, is to target an ideal forth processor and to target work flow to normal processors (maybe a dynamic switch in compiled code and action depending on what processor it loads in on, transparent to the user and programmer).