6 GHz stack machine

[Stephen Pelc]

An MPE client is currently designing a new dual-stack machine. The
predicted performance is 6 GHz (instructions per second). 40 CPUs
occupy less than 1 sqare mm.

It's for real, and they have a paying client for it.

Depending on life, there may be more information at EuroForth 21 in
Rome in September. I have my EU Covid passport already.

Stephen
--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

[Brian Fox]

On 2021-07-02 7:49 AM, Stephen Pelc wrote:
> An MPE client is currently designing a new dual-stack machine. The
> predicted performance is 6 GHz (instructions per second). 40 CPUs
> occupy less than 1 sqare mm.
>
> It's for real, and they have a paying client for it.
>
> Depending on life, there may be more information at EuroForth 21 in
> Rome in September. I have my EU Covid passport already.
>
> Stephen
>

That's really exciting Stephen.

I have always found it tragic that Chuck's CPU ideas didn't find a home
in the bigger world.

If it's allowed can you tell us anything about the architecture.
- Which family it leans towards. shBoom perhaps?
- Maybe it's a clean room design.
- Is there are target application area?
- Are they going to make if C friendly with a few extra registers?

And with my business hat on, once it's developed is there a solid
go to market strategy? Without that it is an academic curiosity.
(again)

[Stephen Pelc]

On 2 Jul 2021 at 15:34:28 CEST, "Brian Fox" <bria...@rogers.com> wrote:

> On 2021-07-02 7:49 AM, Stephen Pelc wrote:
>> An MPE client is currently designing a new dual-stack machine. The
>> predicted performance is 6 GHz (instructions per second). 40 CPUs
>> occupy less than 1 sqare mm.
>>
>> It's for real, and they have a paying client for it.
>>
>> Depending on life, there may be more information at EuroForth 21 in
>> Rome in September. I have my EU Covid passport already.
>>
>> Stephen
>>
>
> That's really exciting Stephen.
>
> I have always found it tragic that Chuck's CPU ideas didn't find a home
> in the bigger world.

One of the interesting parts of this design is that it is done in Verilog
using
industry standard tool chains and is prototyped in FPGAs.

The designers are getting paid for the chips. How much will be open is
yet to be seen/decided. The initial application is pretty specialised.

> If it's allowed can you tell us anything about the architecture.

It's all their own work. I can't tell you more yet.

> And with my business hat on, once it's developed is there a solid
> go to market strategy? Without that it is an academic curiosity.
> (again)

I'm working for the techies, not the capital people. It's for a practical
application that attracts capital people.

Stephen

[Clive Arthur]

I hope they've read the PSC1000 manual. Fetch and store to the return
stack and the ability to drop multiple items from it is dead handy for
locals.

eg
3r@ - copy 3rd R to TOS
5r! - TOS to 5th R
6 rdrop - drop top 6 items from R
and of course r> and >r

--
Cheers
Clive

[Marcel Hendrix]

On Friday, July 2, 2021 at 1:49:54 PM UTC+2, Stephen Pelc wrote:
> An MPE client is currently designing a new dual-stack machine. The
> predicted performance is 6 GHz (instructions per second). 40 CPUs
> occupy less than 1 sqare mm.
>
> It's for real, and they have a paying client for it.
>
> Depending on life, there may be more information at EuroForth 21 in
> Rome in September. I have my EU Covid passport already.

Integer / floating-point? 'C' or Forth-like?
How much memory can it address (and how)?
OS?

-marcel

[none albert]

In article <sbna7h$8r8$1...@dont-email.me>,

That feature was present in the FIETS project in the 80's in FIG chapter
Holland. Chuck Moore with the NOVIX beat us to it,
so we never went far with it. We made an emulator though.
Glad to hear that this feature is useful. With us it never
got battle-tested.
http://www.keesmoerman.nl/e_forth.html
Choose Forth Processors
Note the 1984 award on that page!
>
>--
>Cheers
>Clive
>

Groetjes Albertwww.keesmoerman.nl/e_forth.html
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Paul Rubin]

albert@cherry.(none) (albert) writes:
>>3r@ - copy 3rd R to TOS
>>5r! - TOS to 5th R
>>6 rdrop - drop top 6 items from R
>>and of course r> and >r
>
> That feature was present in the FIETS project in the 80's in FIG
> chapter Holland. Chuck Moore with the NOVIX beat us to it,

The Novix was able to reach into the interior of the R stack like that?
Of course then R is more like a register file.

> http://www.keesmoerman.nl/e_forth.html

This page looks interesting even though I can't read it. I'll try
google translate on it when I get a chance.

[Fourthy Forth]

Stephen, thank you. Good new. Pity Ga not do after all years. Ga so difficult!

[Ilya Tarasov]

пятница, 2 июля 2021 г. в 14:49:54 UTC+3, Stephen Pelc:

> An MPE client is currently designing a new dual-stack machine. The
> predicted performance is 6 GHz (instructions per second). 40 CPUs
> occupy less than 1 sqare mm.

So clickbaiting. 6 GHz meaning 40*150MHz? This is IPS parameter (Instruction
per second), not clock speed. If instruction needs more than 1 cycle in average,
CPI (cycle per instruction) is needed as well.

Intel CPU with 6 cores, 2 threads per core, and 4 GHz clock speed...
6*2*4 = 48 GHz, hmm?

> It's for real, and they have a paying client for it.

I wonder to see a silicon chip designed without a real goal. Of course, toys or
results of author's ambitions may be done just to show it may exist.

[Jurgen Pitaske]

Clickbaiting on CLF - who is there to clickbait?
It might just attract the Peter Forths and Hugh Aguilars.
And they have been stumm until now.

I am quite surprised about your negativity.

If a customer wants to have a chip as you describe it - fine, they pay for it.
They must have a reason to do it. An ASIC will not be cheap.

Non-disclosure Agreements are there for a REASON.
If people here like it or not is actually irrelevant.
This is normal business practice.

I do appreciate the data that Stephen is allowed to disclose.
Something is happening with a chip design and Forth - should be great news for all of us here.
We should all be positive about it.
Nothing to do with clockbaiting.

Assuming they know what they do,
they might have heard about Intel or others,
and there are multi-processor ARM chips out there now,
and they could possibly have seen
that these chips do not achieve what is required in their application.
https://arstechnica.com/information-technology/2020/03/amperes-altra-is-80-arm-cores-of-cloud-native-power-efficient-cpu/


A RISC-V can easily do 5GHz clock frequency
https://www.techpowerup.com/275463/risc-v-processor-achieves-5-ghz-frequency-at-just-1-watt-of-power
and an FPGA RISC-V running mecrisp will be faster than the 150 MHZ you want.
And you could run as many cores as fit into the relevant FPGA.
Then unfortunately without a multiprocessor Forth.
As FPGA NOW. Free of Charge for the cores...

But the designers there might have had some spare gates
to add the pre-divivers to achieve the reduced clock speed you want.

So, I assume they must have a reason and an application that pays for the project cost.

I am actually more interested to hear about 2 things:

What is the target application? Probably AI or crypto mining
How are these CPUs coupled / how do they communicate?

Will it be available for the general market or is this just an internal project and custom design.

I hope it is for the general market, otherwise sales for MPE would be limited to project work unfortunately.
And we want to see commercial Forth Software grow - at least I want to see it.
The best proof of what Forth can achieve.

Or it will there be a multiprocessor VFX - so a Greenarrays++++
For a chip we can all buy a couple of design kits for ...
This fact is hopefully not covered by NDA and Stephen can reveal it.

Fingers crossed for MPE ( and the chip ).

[Paul Rubin]

Ilya Tarasov <ilya74....@gmail.com> writes:

> пятница, 2 июля 2021 г. в 14:49:54 UTC+3, Stephen Pelc:
>> An MPE client is currently designing a new dual-stack machine. The
>> predicted performance is 6 GHz (instructions per second). 40 CPUs
>> occupy less than 1 sqare mm.
>
> So clickbaiting. 6 GHz meaning 40*150MHz?

I took it to mean 40*6ghz = 240gips total. We also don't know the die
size, or what else is on the die. It could be some kind of array
processor for machine vision, or any number of other things.

[Ilya Tarasov]

воскресенье, 4 июля 2021 г. в 21:19:54 UTC+3, Paul Rubin:

Well, I'm really wonder to see people who can estimate 6 GHz as a clock speed.
We must not be disoriented by news and journalists reviews. In reality, clock
speed above 1 GHz is not easy to achieve, regardless of technology node.
Reasons are fine physical effects, non-ideal parameters, variations, non-ideal
routing etc etc etc. If someone draws a schematic and receive about 160 ps
(1/6 Ghz) as a summary gate delay - ok, I can fix he is entering chip making
world at a first time.

[Paul Rubin]

Ilya Tarasov <ilya74....@gmail.com> writes:
> Well, I'm really wonder to see people who can estimate 6 GHz as a
> clock speed.

Chip designers, it sounds like.

> In reality, clock speed above 1 GHz is not easy to achieve, regardless
> of technology node.

Well, chip designers manage to do it.

> If someone draws a schematic and receive about 160 ps (1/6 Ghz) as a
> summary gate delay

Do EDA tools not mostly automate that? I.e. the designer writes HDL
rather than drawing a schematic. The tools handle all the layout etc.

[Ilya Tarasov]

> Clickbaiting on CLF - who is there to clickbait?
> It might just attract the Peter Forths and Hugh Aguilars.
> And they have been stumm until now.

People are free in general and I have no goal to attract someone.
You are talking about a kind of cult with certain hierarchy and
'allowed' phrases about key points.

> I am quite surprised about your negativity.

Not every mention of Forth should generate a positive reaction

> If a customer wants to have a chip as you describe it - fine, they pay for it.
> They must have a reason to do it. An ASIC will not be cheap.

I see no list of chip features. There is only mention 'Forth has another success
but we will not tell you details'.

> I do appreciate the data that Stephen is allowed to disclose.
> Something is happening with a chip design and Forth - should be great news for all of us here.
> We should all be positive about it.

I was quite positive (in general) 10+ years ago when TechnoForth TF16 CPU was implemented
in 0.35 um silicon. After this, TechnoForth (claimed theyselves as only true Forth team in Russia)
goes to bankrupt. Slowly, step by step, but inevitable. Silicon implementation was a kind of last
chance for them to keep impressions with no real base. Indeed, their code was poor and overall
architecture inconsistent to application domain and technology. Their position, however, was
'it is Forth, and we are professional forthers, so you have no chance to understand our wisdom'.
Until bankruption.

> Nothing to do with clockbaiting.

6 GHz is clickbaiting.

> A RISC-V can easily do 5GHz clock frequency
> https://www.techpowerup.com/275463/risc-v-processor-achieves-5-ghz-frequency-at-just-1-watt-of-power

Chuck Norris can easily do many things. Do you can the same? Don't tell me about chip topology unless
you have chips routed by you personally. This is a true art with a huge list of potential problems.

> and an FPGA RISC-V running mecrisp will be faster than the 150 MHZ you want.
> And you could run as many cores as fit into the relevant FPGA.
> Then unfortunately without a multiprocessor Forth.
> As FPGA NOW. Free of Charge for the cores...

JFF design (real Forth CPUs, though).
http://fforum.winglion.ru/viewtopic.php?f=3&t=3309&p=48880#p48880

It seems you will never turn to real activity...
Keep collecting rumors about possible Forth applications ;)

> Will it be available for the general market or is this just an internal project and custom design.
>
> I hope it is for the general market, otherwise sales for MPE would be limited to project work unfortunately.

Exactly then same as for TF16 or SeaForth. Another round of empty dreams?

> Fingers crossed for MPE ( and the chip ).

Crossed fingers will certainly prevent you from doing something :)))

[Jurgen Pitaske]

Ilya,
we can only take what Stephen is allowed to mention.
Let us be happy that something happens on the Forth front.

How much these clock speeds or Instruction execution times vary in either direction is unclear
and will only be known when the design has been signed off at the silicon manufacturer
- or after testing when the chip exists, as you know,
and is not really important for now.
Let's hope the world has access to these chips and creates clickbaits for Forth anywhere..

[Ilya Tarasov]

> > If someone draws a schematic and receive about 160 ps (1/6 Ghz) as a
> > summary gate delay
> Do EDA tools not mostly automate that? I.e. the designer writes HDL
> rather than drawing a schematic. The tools handle all the layout etc.

OMG, you are completely missing this. EDA tools for silicon are not
masterpiece generators, it looks like MS Paint with basic set of features,
and you need to create something really smart. Automatization is very limited
because there are many factorial-based complexity in place&route algorithms.
Even for FPGA, full automatization of optimal designing is impossible. Consider
you have now not predefined layout with only routing required (predefined also
and needed to connect by special points), but a clear piece of silicon with many
layers and many modifications of every logic gate. If an idea is 'Intel can do it,
so we can do it too, especially because we are touched by the Forth spirit', you
will definitely fail.

[Jurgen Pitaske]

99% of the people here with fingers crossed - including YOU - can only make it better,
as none of us
are involved in this design
or the VFX software adaptations.

So, let us just be supportive.
And positive.
The future will tell - or do you have anything more positive to offer?

[Ilya Tarasov]

> Ilya,
> we can only take what Stephen is allowed to mention.
> Let us be happy that something happens on the Forth front.

I will be happy if many Forth projects will be active, with many
approaches and a rich base of practical applications. Shrinking
Forth to a limited set of 'blessed' leaders and a fan club will lead
to fail of false leaders and disappointment of fans.

[Jurgen Pitaske]

A language is a tool for applications
- the old hammer and nail example comes to mind.

If a language - Forth included -
is not used in real applications
the world will not bother
but just use other tools which work better - or they like more.

People who like Forth, or hobbyists
will continue to use the 100+ Forth variants they now play with for the next 50 years or longer.

[Stephen Pelc]

On 4 Jul 2021 at 17:00:50 CEST, "Ilya Tarasov" <ilya74....@gmail.com>
wrote:

> пятница, 2 июля 2021 г. в 14:49:54 UTC+3, Stephen Pelc:
>> An MPE client is currently designing a new dual-stack machine. The
>> predicted performance is 6 GHz (instructions per second). 40 CPUs
>> occupy less than 1 sqare mm.
>
> So clickbaiting. 6 GHz meaning 40*150MHz? This is IPS parameter (Instruction
> per second), not clock speed. If instruction needs more than 1 cycle in
> average,
> CPI (cycle per instruction) is needed as well.

What I can say is limited by what I know and what I am allowed to say. MPE is
doing some tool-making for them. They have completed a fair number of chips.

No click baiting. Let's assume that 6Hz is a target figure for some unknown
process
- i.e. I don't know what it is. From what I do know, I would expect a figure
in excess
of 2GHz. That's per CPU. And I know very little about chip and FPGA design.

150MHz per CPU would happen on an FPGA.

>> It's for real, and they have a paying client for it.
>
> I wonder to see a silicon chip designed without a real goal. Of course, toys or
> results of author's ambitions may be done just to show it may exist.

Yes, there's a goal but it's not published yet. For Marcel's benefit,
it's a 32 bit integer CPU with floating point and custom instructions. The
custom instructions help with the goal.

Stephen

[Ilya Tarasov]

> So, let us just be supportive.
> And positive.
> The future will tell - or do you have anything more positive to offer?

Following things are just an illusion of support:
- likes
- subscriptions
- automatic acceptance of every news about Forth

Following things are closer to support:
- experimental/modeling verifications
- technical questions
- discussions
- clarifying counterexamples to avoid negative effects
- comparisons and methodology summarizing

[Hugh Aguilar]

On Sunday, July 4, 2021 at 1:00:53 PM UTC-7, jpit...@gmail.com wrote:
> On Sunday, 4 July 2021 at 20:49:06 UTC+1, Ilya Tarasov wrote:
> > 6 GHz is clickbaiting.
> > > A RISC-V can easily do 5GHz clock frequency
> > > https://www.techpowerup.com/275463/risc-v-processor-achieves-5-ghz-frequency-at-just-1-watt-of-power
> > Chuck Norris can easily do many things. Do you can the same? Don't tell me about chip topology unless
> > you have chips routed by you personally. This is a true art with a huge list of potential problems.

Good analogy, Ilya!
I have found, when trying to discuss MFX and the out-of-ordering of the instructions,
that people will say this is easy, and they read a magazine article about it, etc..
Maybe easily done by Chuck Norris! lol In practice, not done by anybody other than me.

> > > Fingers crossed for MPE ( and the chip ).
> > Crossed fingers will certainly prevent you from doing something :)))

Another good analogy, Ilya!
It is certainly difficult to get any work done with the fingers crossed. lol

> 99% of the people here with fingers crossed - including YOU - can only make it better,
> as none of us
> are involved in this design
> or the VFX software adaptations.
>
> So, let us just be supportive.
> And positive.

Juergen Pintaske disgusts me.
He wants the Forth community to cross their fingers for Stephen Pelc. lol
Shall we also bring Stephen coffee, shine his shoes, and sharpen his pencils?
How about a free blow-job? The Forth community is queuing up for the privilege!

> The future will tell - or do you have anything more positive to offer?

I wrote MFX back in 1994. That seemed to me like something positive to offer.
MFX was certainly a lot of work --- I had to use my brain to figure out how to do it!
Tom Hart now refuses to admit that I wrote MFX --- must be mad because
I never brought him coffee, shined his shoes or sharpened his pencils.
If he was hoping for a blow-job he should have hired John Passaniti instead of me.

[Paul Rubin]

Ilya Tarasov <ilya74....@gmail.com> writes:
> OMG, you are completely missing this. EDA tools for silicon are not
> masterpiece generators, it looks like MS Paint with basic set of features,
> and you need to create something really smart.

Ok, that's interesting to hear, I was under the impression that you
write some HDL and the EDA and the fab house take care of (most of the rest).

> Automatization is very limited because there are many factorial-based
> complexity in place&route algorithms.

I think this specific issue is not too bad and some tools use SAT
solvers for routing. The worst case instances are very hard to solve,
but they don't come up that often in practice. I've heard solving SAT
compared with freezing water: if it's below temperature X, it's solid
ice and that's easy to understand. If it's above X, it's liquid water
and that's also easy to understand. It's only difficult if the
temperature is almost exactly X, so you get a complicated phase change
phenomenon that is very hard to analyze. Similarly, the "hard" SAT
instances seem to all have a certain critical density of clauses.

Here is a good tutorial on SAT and SMT solvers:

https://yurichev.com/writings/SAT_SMT_by_example.pdf

> If an idea is 'Intel can do it, so we can do it too, especially
> because we are touched by the Forth spirit', you will definitely fail.

I think the OKAD approach mirrors other stuff written in the 1980's
after Mead & Conway's book "Introduction to VLSI Design" shook things up
a lot. You'd lay out rectangles on a screen and iirc, if a red wire
crossed a green wire, the intersection was a transitor. People did
design chips using those methods, including the GA144, but it was a lot
of work and probably becomes unmanageable for much more complex chips.

I took one of those classes so I have a little bit of familiarity with
that old stuff, but today's stuff is much fancier and I don't know much
about it, beyond having looked at some HDL code here and there.

[Jurgen Pitaske]

It was clear you would raise your ugly head as I had said in the first lines.

But that you would post more disgusting stuff than usual was a surprise -
and as usual not related to the theme of the post.

[Rick C]

On Monday, July 5, 2021 at 1:12:18 AM UTC-4, Paul Rubin wrote:
> Ilya Tarasov <ilya74....@gmail.com> writes:
> > OMG, you are completely missing this. EDA tools for silicon are not
> > masterpiece generators, it looks like MS Paint with basic set of features,
> > and you need to create something really smart.
> Ok, that's interesting to hear, I was under the impression that you
> write some HDL and the EDA and the fab house take care of (most of the rest).

You can do that, but with devices that are not full custom. There are degrees of customization in ASICs. Well, there used to be gate arrays which are like metal layer programmed FPGAs. But I seem to recall they have largely been squeezed out by FPGAs getting bigger and faster. They should still be around since the full custom parts continue to get more expensive as the feature size gets smaller. Gate arrays are the traditional way of lowering the cost of FPGAs once you have been in production and are confident in the design. I know Xilinx started a program where they use the same die as their production parts, but only test to your design requirements lowering the test time, defect rate and so cost.

> > If an idea is 'Intel can do it, so we can do it too, especially
> > because we are touched by the Forth spirit', you will definitely fail.
> I think the OKAD approach mirrors other stuff written in the 1980's
> after Mead & Conway's book "Introduction to VLSI Design" shook things up
> a lot. You'd lay out rectangles on a screen and iirc, if a red wire
> crossed a green wire, the intersection was a transitor. People did
> design chips using those methods, including the GA144, but it was a lot
> of work and probably becomes unmanageable for much more complex chips.
>
> I took one of those classes so I have a little bit of familiarity with
> that old stuff, but today's stuff is much fancier and I don't know much
> about it, beyond having looked at some HDL code here and there.

I seem to recall some of the Forth community who were involved in the GA144 would denigrate Spice because they tried to model the transistors used in the part and got a poor result. But Spice is just a tool, not a model and the garbage in - garbage out rule definitely applies. It was a bit strange they held up this example as some sort of proof that traditional tools don't work in spite of the reality of working chips with any number of transistors you can imagine.

--

Rick C.

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

[Ilya Tarasov]

понедельник, 5 июля 2021 г. в 08:12:18 UTC+3, Paul Rubin:

> Ilya Tarasov <ilya74....@gmail.com> writes:
> > OMG, you are completely missing this. EDA tools for silicon are not
> > masterpiece generators, it looks like MS Paint with basic set of features,
> > and you need to create something really smart.
> Ok, that's interesting to hear, I was under the impression that you
> write some HDL and the EDA and the fab house take care of (most of the rest).

I didnt write EDA tools. Even using tools is a kind of art. Industry leading tools
like Cadence or Synopsis are a large set of utilities with complex design flow.
There is no 'pushbutton flow'.

> Here is a good tutorial on SAT and SMT solvers:

Looks like a single screw for building a car.

> https://yurichev.com/writings/SAT_SMT_by_example.pdf
> > If an idea is 'Intel can do it, so we can do it too, especially
> > because we are touched by the Forth spirit', you will definitely fail.
> I think the OKAD approach mirrors other stuff written in the 1980's
> after Mead & Conway's book "Introduction to VLSI Design" shook things up
> a lot. You'd lay out rectangles on a screen and iirc, if a red wire
> crossed a green wire, the intersection was a transitor. People did
> design chips using those methods, including the GA144, but it was a lot
> of work and probably becomes unmanageable for much more complex chips.

OKAD is a good example of how wrong and naiv people may be. VLSI design is
not a laying rectangles.

There is a story about a worker who wanted to assemble a television set.
He annoyed engineers by asking them for a schematic for a specific CRT.
They gave him such a scheme in the end. When after a while they asked
him ironically how he was doing with the TV, he brought them home and
they were shocked. The entire wall was covered with a sheet of plywood,
on which parts were nailed, assembled exactly as shown in the diagram.
This TV worked! OKAD looks the same. Printed circuit boards differ
significantly from circuits, and silicon dies differ significantly from circuits
and HDLs. There are so many design rules that are collected in huge
technology files. These rules are validated in CAD, and it is a difficult
skill to understand which rules and how tightly should be set in a project.

[Paul Rubin]

Ilya Tarasov <ilya74....@gmail.com> writes:
> There are so many design rules that are collected in huge
> technology files. These rules are validated in CAD, and it is a difficult
> skill to understand which rules and how tightly should be set in a project.

Design rules in the "old days" were pretty simple: X unit line width, Y
units between lines, Z extra space around any via. There may have been
one or two other parameters but DRC was pretty simple. There was a
timing simulator that worked by estimating capacitance of rectangles.
People did make working digital chips this way. SPICE was more for
analog chips and if you were after higher performance than you could get
with the simple stuff.

It's interesting to hear that the workflow from HDL to finished chips is
not as simple as I'd imagined. Oh well.

[Jurgen Pitaske]

Just for people who might have the time and look for some background:
One extreme - all of the aspects involved in ASICs and the complexity:
https://anysilicon.com/
And the other extreme, probably the closest there is to Chuck's way at the time
https://www.asic-gmbh.de/array_engl.html
Here you can even do Mixed-Signal ASIC prototyping using a breadboard
https://www.asic-gmbh.de/breadboard_engl.html
I remember the ASIC they designed with EEPROM at the time
- no microprocessor yet on-board - used by a model train company.
Manufactured by Hughes microelectronics

[Ilya Tarasov]

вторник, 6 июля 2021 г. в 09:35:16 UTC+3, Paul Rubin:

> Ilya Tarasov <ilya74....@gmail.com> writes:
> > There are so many design rules that are collected in huge
> > technology files. These rules are validated in CAD, and it is a difficult
> > skill to understand which rules and how tightly should be set in a project.
> Design rules in the "old days" were pretty simple: X unit line width, Y
> units between lines, Z extra space around any via. There may have been
> one or two other parameters but DRC was pretty simple. There was a
> timing simulator that worked by estimating capacitance of rectangles.
> People did make working digital chips this way. SPICE was more for
> analog chips and if you were after higher performance than you could get
> with the simple stuff.

It works up to 250 or 180 nm, maybe. Just like breadboard and wires can be
used for 8 MHz MCU in a DIP package. High-frequency effects will add
problems for 100 MHz clock, and will prevent normal working of DDR3
memory - multilayer PCB wit controlled impedance, differential routing,
shielding, decoupling capacitors etc is strictly required.

For ASIC, at least two major technology shifts took place. First was at 130-90
nm, when a wire delay became equal/greater than a gate delay. Tricks with
short spikes, asynchronous schemes, and many other things are gone.
Design must be fully synchronous, clocked by carefully built clock tree.
Second is near 28 nm, with several non-obvious problems. Clock tree is no
longer able to cover an entire chip area - welcome to Globally Asyncronous,
Locally Synchronous architectures (GALS). Variations (process, voltage,
temperature) are huge, so timing analysis is very complex. For ASICs, local
overheating is a little bonus - is it not enough to place and route, active gates
may be so dense, so temperature may raise too high in a certain small area.
Oh, above 1 GHz a pack of routing tricks are also needed. For example, a net
may require differential and co-planar routing with shielding around curves.
This is a black magic known by people who are deeply inside physical design
process - I cannot provide a complete list of what is needed.

> It's interesting to hear that the workflow from HDL to finished chips is
> not as simple as I'd imagined. Oh well.

Even for FPGA, synthesis and implementation are separated in the CAD
workflow. For ASICs, implementation is a complete different from a
synthesis, heavily dependent on a factory and technology process.

[Ilya Tarasov]

> Good analogy, Ilya!
> I have found, when trying to discuss MFX and the out-of-ordering of the instructions,
> that people will say this is easy, and they read a magazine article about it, etc..
> Maybe easily done by Chuck Norris! lol In practice, not done by anybody other than me.

There are a lot of things which cannot be done from a first attempt. Yes, out-of-order
is not an easy thing, and certainly require some exercices to get at least experience.
It's funny many hobbyists expect that any problem will be solved by itself, simply
because the Forth will be used.

> Juergen Pintaske disgusts me.
> He wants the Forth community to cross their fingers for Stephen Pelc. lol
> Shall we also bring Stephen coffee, shine his shoes, and sharpen his pencils?
> How about a free blow-job? The Forth community is queuing up for the privilege!

'The larger the cabinet, the louder it falls' :)
I saw SP-Forth community fall and TechnoForth fall. Ok, SP-Forth is still exist and
available to download, but very far from success. Both teams wanted to be leaders
of community and were catched by a kind of a deadlock. They started to waiting for
followers who must write applications, but their fans are started to waiting bright
news about their success. No serious activity as a result. I told to Andrey Cherezov
he should think about strategic plans, but he was blinded by the temporary success
of SP-Forth. His arguments was very like to what I can see here. Ok when... ;)

[Fourthy Forth]

Maybe somebody not know how to design a forth procese.

Regular material, without deviation, always have statistically same action of action and interference. Not E=mc2, but tell a lot..

[Hugh Aguilar]

On Tuesday, July 6, 2021 at 1:42:17 AM UTC-7, Ilya Tarasov wrote:
> > I have found, when trying to discuss MFX and the out-of-ordering of the instructions,
> > that people will say this is easy, and they read a magazine article about it, etc..
> > Maybe easily done by Chuck Norris! lol In practice, not done by anybody other than me.
> There are a lot of things which cannot be done from a first attempt. Yes, out-of-order
> is not an easy thing, and certainly require some exercices to get at least experience.

Well, I solved the out-of-ordering of the instructions for the MiniForth on the first attempt.
I had a solution that worked, anyway.
Steve Brault complained that in some cases my assembler's solution was not optimal.
It was possible to hand-code machine-language that did the same thing but was more
efficient in the sense of having fewer NOP instruction inserted.
I said that it was necessary for the assembly-language programmer to help the assembler
by writing his code in a "riscified" manner. Steve Brault complained that this was not
documented anywhere and he did not know what I meant.
I said that this was very similar to what Michael Abrash described in:
"Zen of Code Optimization" that covered the Pentium with its U and V pipes.
The idea is simple. You hold values in registers for as long as possible. You don't load a
register and then immediately use the register. You load the register, you do something
unrelated, then you use the register --- the idea is that the unrelated code will parallelize
with loading the register and/or with using the register. I never heard any further complaints
from Steve Brault, so I assume he understood what I was telling him --- I never saw any of
his assembly-language code though (except the function that did 16-bit integer addition),
so I don't know what quality level he was achieving. I never saw any of the motion-control
code written in MFX because the motion-control program was proprietary to Testra.
John and Tom Hart were very afraid that I would steal it and go start my own company
selling motion-control boards in competition with Testra. That was paranoia. I wasn't
going to do that, and this was way beyond my ability anyway.

> It's funny many hobbyists expect that any problem will be solved by itself, simply
> because the Forth will be used.

Programmers tend to be overly focused on the programming language, and not
focused enough on algorithms --- but algorithms can be ported between languages.

Telling people about writing MFX doesn't impress them. They always tell me that
they don't use Forth so all of this is irrelevant --- they are C programmers.
In actuality, a VLIW processor could be built to run C code, and my assembler
ideas would transfer over to it smoothly. Nobody ever builds VLIW processors though.
You are the only person I am acquainted with who knows what a VLIW processor is.
Quite a lot of people use the term VLIW as a synonym for "super-duper."

We had a thread with this hilarious title: "Zero Instruction Computing?"
https://groups.google.com/g/comp.lang.forth/c/dPvjIMFtRVA/m/PEPLhCtvBgAJ

On Sunday, December 27, 2020 at 11:59:07 PM UTC-7, gnuarm.del...@gmail.com wrote:
> It is a VLIW format with individual control points.

Whatever!

[Fourthy Forth]

On Monday, 5 July 2021 at 6:24:31 am UTC+10, Stephen Pelc wrote:
> On 4 Jul 2021 at 17:00:50 CEST, "Ilya Tarasov" <ilya74....@gmail.com>
> wrote:
> > пятница, 2 июля 2021 г. в 14:49:54 UTC+3, Stephen Pelc:

> doing some tool-making for them. They have completed a fair number of chips.

..

> it's a 32 bit integer CPU with floating point and custom instructions. The
> custom instructions help with the goal.
>
> Stephen

Is this GA company. Done number chips and advanced 32bit list. Will run around in circles streaming, or from memory plus stream?

[Brad Eckert]

That is impressive. It must be at a reasonably small process node like 28nm, which is affordable for MPW prototype chips.
At 28nm, you get 8M bits of RAM per square mm. Let's suppose this chip has 5M bits of RAM.
That would be 128K bits, or 4K 32-bit words, per core. Sounds about right.

I watched Chuck Moore's interview where he talked about designing his own computer chips with his his own tools. He looked good.
My eyeroll moment was when he said that he couldn't build large, fast RAMs. Presumably they aren't OKAD-friendly.
Okay, but isn't that the trick? Modern processors are big RAMs with processing logic bolted on here and there.

At today's prices, small companies can build their own even less ambitious Forth chips that make sense at the 130nm to 350nm nodes.
130nm is very popular because the masks can be made by laser instead of much slower e-beam and there's no need for
multi-layer phase shift masks. The wafer costs aren't too bad either.
With the current supply crunch, I suspect more companies are asking "Why are we still buying off-the-shelf MCUs?".

What's more is that Forth is the most elegant way of computing ever invented. It taps into mathematical principles that are only now
being discussed in terms of the mathematics of functional programming. Concatenative lambda calculus supported directly in
hardware is very good. Hardware stacks, also very good. GreenArrays proved that stacks are in fact green.

This will help create more Forth programmers. The good thing about a language ahead of its time is that its time hasn't passed.
Perhaps Forthers treat programming the way the French treat food. Would that make C the equivalent of English cuisine?

[Jurgen Pitaske]

Just had a look at the latest news on theGreenarrays website, copied from there:

Latest developments:

As of Spring 2021, shipments of the EVB002 evaluation kit and of G144A12 chips continue to be made.
The arrayForth 3 integrated development system is in use with no reported problems.
Design of a new chip, G144A2x, continues; this will be upward compatible with the G144A12,
with significant improvements.
Development of Application Notes, including that of a solftware defined GPS receiver, continues.

Has there been a hint somewhere when this new chip will be out? It seems to be shifting.

[dxforth]

On 5/08/2021 15:46, Brad Eckert wrote:
> ...

> This will help create more Forth programmers. The good thing about a language ahead of its time is that its time hasn't passed.
> Perhaps Forthers treat programming the way the French treat food. Would that make C the equivalent of English cuisine?
>

If Forth is anything like the cheap frozen French import pastries that
turn up on local supermarket shelves, then it suits consumers with more
imagination than taste.

[Stephen Pelc]

On 5 Aug 2021 at 06:17:10 BST, "Fourthy Forth" <fourth...@gmail.com> wrote:
>
> Is this GA company.

No.

> Done number chips and advanced 32bit list. Will run around in circles
> streaming,
> or from memory plus stream?

I don't understand what you mean. Programs run from memory with separate
areas for code and data.

Stephen

[Stephen Pelc]

On 5 Aug 2021 at 06:46:41 BST, "Brad Eckert" <hwf...@gmail.com> wrote:
>
> Perhaps Forthers treat programming the way the French treat food. Would that
> make C the equivalent of English cuisine?

Please, USAnian cuisine - lots of fat and sugar.

Stephen

[Fourthy Forth]

On Thursday, 5 August 2021 at 10:25:48 pm UTC+10, Stephen Pelc wrote:
> On 5 Aug 2021 at 06:17:10 BST, "Fourthy Forth" <fourth...@gmail.com> wrote:
> >
> > Is this GA company.
>
> No.

Thank you

> > Done number chips and advanced 32bit list. Will run around in circles
> > streaming,
> > or from memory plus stream?
> I don't understand what you mean. Programs run from memory with separate
> areas for code and data.
>
> Stephen

Parallel serial process, small memory, program hard, vers normal

[Brad Eckert]

On Friday, July 2, 2021 at 6:34:32 AM UTC-7, Brian Fox wrote:

> On 2021-07-02 7:49 AM, Stephen Pelc wrote:
> > An MPE client is currently designing a new dual-stack machine. The
> > predicted performance is 6 GHz (instructions per second). 40 CPUs
> > occupy less than 1 sqare mm.
> >

> > It's for real, and they have a paying client for it.
> >

> > Depending on life, there may be more information at EuroForth 21 in
> > Rome in September. I have my EU Covid passport already.
> >
> > Stephen
> >
> That's really exciting Stephen.
>
> I have always found it tragic that Chuck's CPU ideas didn't find a home
> in the bigger world.
>
I would suppose it uses lessons from shBoom but puts stacks in hardware.
In a modern chip, wire delays trump logic delays.
A hardware stack is a bidirectional shift register where all of the bits are adjacent so there are no long wires.
That allows stacks to run at high speed, much faster than a decently-sized memory.
So, a shBoom type of architecture with 8-bit instructions in a 32-bit group makes sense.
6 GHz instructions means 1.5 GHz memory.

[Rick C]

I believe that much static RAM would consume a fair amount of current. In devices like this power consumption is typically an important detail to control. So it would be useful to learn what the device actually is using.

> I watched Chuck Moore's interview where he talked about designing his own computer chips with his his own tools. He looked good.
> My eyeroll moment was when he said that he couldn't build large, fast RAMs. Presumably they aren't OKAD-friendly.
> Okay, but isn't that the trick? Modern processors are big RAMs with processing logic bolted on here and there.

"Modern" processors aren't designed to run Forth apps and vice versa. Isn't that the issue being addressed by such chips?

> At today's prices, small companies can build their own even less ambitious Forth chips that make sense at the 130nm to 350nm nodes.
> 130nm is very popular because the masks can be made by laser instead of much slower e-beam and there's no need for
> multi-layer phase shift masks. The wafer costs aren't too bad either.
> With the current supply crunch, I suspect more companies are asking "Why are we still buying off-the-shelf MCUs?".

ADC, DAC and other analog I/Os as well as the many digital peripherals... that's a big part of the reason. There's a lot of IP amortized in such off the shelf MCUs, not to mention the large code base and tool sets. Even when building a custom chip it is not very common to roll your own CPU to put in it. There has to be a compelling case to support such an investment.

> What's more is that Forth is the most elegant way of computing ever invented. It taps into mathematical principles that are only now
> being discussed in terms of the mathematics of functional programming. Concatenative lambda calculus supported directly in
> hardware is very good. Hardware stacks, also very good. GreenArrays proved that stacks are in fact green.

Not to be snide, but I wasn't aware that GreenArrays proved much of anything with the GA144 except that a CPU chip could be designed that sounded so good and was nearly completely ignored by anyone building products. It is one of the most unrealistic CPUs ever conceived, worse than the RCA 1802 COSMAC. As odd as it was, it has found a home in the space community... somehow.

> This will help create more Forth programmers. The good thing about a language ahead of its time is that its time hasn't passed.
> Perhaps Forthers treat programming the way the French treat food. Would that make C the equivalent of English cuisine?

You can't say the time for Forth has passed. I'm not sure it ever existed... did it? Certainly it is not yet to come.

--

Rick C.

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

[Brad Eckert]

On Tuesday, August 17, 2021 at 5:32:21 AM UTC-7, gnuarm.del...@gmail.com wrote:
> I believe that much static RAM would consume a fair amount of current. In devices like this power consumption is typically an important detail to control. So it would be useful to learn what the device actually is using.

That's an interesting thought, but it seems like being performance-oriented they aren't running off batteries. But isn't this a loaded question? Otherwise, why would you start off your response with a non-issue?

> "Modern" processors aren't designed to run Forth apps and vice versa. Isn't that the issue being addressed by such chips?

They are designed to run apps. Apps are CPU coupled to memory. I would imagine "the issue" being addressed has to do with the C programming model.
Maybe they are philosophically opposed to RISC's overhead of nested calls. Of course, saving every return address to the stack isn't cheap. Having stacks in memory, definitely not cheap.

But isn't this a language problem? Now we are penalizing factoring?

> ADC, DAC and other analog I/Os as well as the many digital peripherals... that's a big part of the reason. There's a lot of IP amortized in such off the shelf MCUs, not to mention the large code base and tool sets. Even when building a custom chip it is not very common to roll your own CPU to put in it. There has to be a compelling case to support such an investment.

I would characterize that as an investment in our youth. Of course, there is the sunk cost problem. But, Google (why does it have to be them?) found a way around some of that. eFabless gives your kids (or your inner kid) a playground to just do interesting things in.

> Not to be snide, but I wasn't aware that GreenArrays proved much of anything with the GA144 except that a CPU chip could be designed that sounded so good and was nearly completely ignored by anyone building products. It is one of the most unrealistic CPUs ever conceived, worse than the RCA 1802 COSMAC. As odd as it was, it has found a home in the space community... somehow.

Isn't this about where you are personally? Chuck Moore did in fact greatly enrich GlobalFoundries by fixing their broken fab models when it really mattered. The benefits to humanity of Chuck Moore are profound. That is a life well-lived.

[Paul Rubin]

Brad Eckert <hwf...@gmail.com> writes:
> Chuck Moore did in fact greatly enrich GlobalFoundries by fixing their
> broken fab models when it really mattered.

Wait, what? Do you mean OUR Chuck Moore? You may be confusing him with
another Chuck Moore:

https://en.wikipedia.org/wiki/Charles_R._Moore_(computer_engineer)

[Brad Eckert]

Wait, what? There's moore than one?

Yeah, that whole temperature model being important when nobody thought it mattered.
Well of course it matters if scaling matters. So, GlobalFoundries became the guys who could deliver.

Shouldn't we be building Forth systems just because we can? Just to pay tribute to such a remarkable human being as Charles H. Moore?

Forth was always doomed because of the sunk-cost problem. Sorry, no hiding the source in libraries, the source is the library. So yes. Forth was always ahead of its time. It doesn't play in the 3D money game. It's a whole different thing. Oh the times, they are a-changing.

C is a legacy of what? What did the 20th century get you? Bigger KaBooms? How will the industry paradigm overcome the same old problems that can't be ignored anymore? Isn't library code the real problem? Notice how Chuck always challenged his thinking. What a wizard.

The soul of a machine, isn't that the heart of the problem? This separation of the creator from his/her creation for reasons of financial empire. This empire of illusion. Too bad Chuck fell for the illusion, but it gave us Forth. Libraries are not your friend because they are built on this legacy.
No, if you are out to build something to materially benefit all of humanity, isn't Forth really your only sustainable option?

Look at Woody Harrelson as a role model for this. Lives in Maui not far from our own Elizabeth Conklin. Had his wedding bands custom made from gold dust panned from streams in Northern California. Not far from Chuck's old stomping grounds. He could have gotten that gold off the market. But he didn't.

[Paul Rubin]

Brad Eckert <hwf...@gmail.com> writes:
> Well of course it matters if scaling matters. So, GlobalFoundries

> became the guys who could deliver... Shouldn't we be building Forth

> systems just because we can? Just to pay tribute to such a remarkable
> human being as Charles H. Moore?

Your entire post is completely confusing, but particularly: are you
saying that Charles H. Moore (the inventor of Forth) had something to do
with GlobalFoundries? Or are you thinking of Charles R. Moore, a
different person who was an architect at AMD, which later spun off its
fab division to become GlobalFoundries? It sounds more likely to me
that you are thinking of Charles R. Moore, but I can't tell.

> Too bad Chuck fell for the illusion, but it gave us Forth. Libraries
> are not your friend because they are built on this legacy.

I completely don't understand what point you are making about libraries.

> No, if you are out to build something to materially benefit all of
> humanity, isn't Forth really your only sustainable option?

This I don't understand either. Forth is interesting historically and
maybe in the present day, but of course there are other ways to write
software, and even ways to materially benefit humanity without involving
software.

> Look at Woody Harrelson as a role model for this. Lives in Maui not
> far from our own Elizabeth Conklin. Had his wedding bands custom made
> from gold dust panned from streams in Northern California.

That sounds pretty cool. We haven't heard from Elizabeth here lately.
I hope she comes back.

[Brad Eckert]

Oh, I thought you were making a joke. My mistake. My recollection of the Charles H. Moore saga involves him trying desperately trying to make his OKAD tool
work with the foundry-supplied transistor models. These models were bad, and he made no secret of his use of GlobalFoundries as his supplier. The resulting corrections to that fab's "secret sauce" would be reasonably assumed to have important downstream ramifications.
Of course, if it hadn't been "our Chuck" it would have been someone with real money so the problem would have been fixed, after the crucial market window.

Other than that, my post is more to clarify my own thoughts on the metaphysics of sustainably sourced computing. Way too Zen. How this plays out in the hardware world is anyone's guess. Google is pioneering a new model that allows software guys to make real chips on real foundries. Yup, there are all kinds of languages and all kinds of tools. Did you write them? Did someone who loves you write them? What were their motivations?

Are those motivations something you want to buy into? Google's FOSS commitment seemed to be a showstopper for the fabs, but they found a way. Their way is something I can buy into.

I own an Apple smartphone and sure wish I didn't. Yup, I think the old duderino is about to go Android. I would love Apple if they weren't so cut-throat gangster. Apple is the new Philip Morris. Not something anyone should buy into, but that's me.

You seem to share the same view of historical Forth as Charles H. Moore. It's an interesting footnote, but it's not going anywhere. Forth is words and stack. What we build around that is up to us. That's why the multicore Forth chip - because they can. C is also an interesting historical footnote. But as you can see, it's still around. Why? Libraries. You know, the things that tie us to our past. The things Chuck tried to warn us about. Isn't the point of computing to move beyond the structures of the past? Isn't that why he left Forth Inc? Everyone wanted to canonize their past work, just like the C guys, instead of leaving Forth open to endless conceptualization. Here's your virtual machine, this is what Forth is. No it isn't, it's only one embodiment of an underlying informatics based on stacks.

I can see how reinventing the wheel doesn't make business sense. But what if reinventing the wheel is the point? That's what makes computer programming a kind of Zen practice. Keep taking away the old, not continue to build upon it. Libraries make us slaves to our past. Standing on the shoulders of giants is only as good as the giants themselves. If you're in for the hero's journey, Forth is probably more your thing. Yoda and floating rocks sold separately.

[Paul Rubin]

Brad Eckert <hwf...@gmail.com> writes:
> C is also an interesting historical footnote. But as you can see, it's
> still around. Why? Libraries. You know, the things that tie us to our
> past. The things Chuck tried to warn us about.

C is still relevant because of the humongous amount of historical
programs written in it, by which I mean large programs like the Linux
kernel, not libraries in particular. There really isn't that much
library code for C compared with other languages. You have to do more
yourself. C is historical in that relatively few people today, when
they decide to embark on a large new software project, choose to write
it in C. C programming today is either small embedded applications, or
maintenance programming of older projects.

Library ecosystems spring up around new languages relatively quickly:
look at Go, Rust, Ruby, etc., all of which are much newer than C and
have plenty of libraries. This is especially true since you can usually
call C code from other languages.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>Your entire post is completely confusing, but particularly: are you
>saying that Charles H. Moore (the inventor of Forth) had something to do
>with GlobalFoundries? Or are you thinking of Charles R. Moore, a
>different person who was an architect at AMD, which later spun off its
>fab division to become GlobalFoundries?

Looking at the wikipedia page of Charles R. Moore, he was a computer
architect, and while that is adjacent to circuit design, I doubt that
he made substantial contributions to circuit design.

Concerning Charles H. Moore, he went from programming down to
programming language design (Forth), to computer architecture (Novix
ff.), and finally to circuit design (OKAD).

However, he has always used outdated processes (and I remember the
name MOSIS, but not Globalfoundries), so it's not very likely that he
finds problems and solutions that make a difference for a lot of other
products.

He also uses the processes in unusual ways: At EuroForth he mentioned
that he had a problem with one particular design rule (basically his
design was not dense enough), and Bernd Paysan commented that usual
circuits don't have a problem with that rule; so it can easily be that
he discovered things about the process that are not in the usual
models, but it's less clear that this discovery helps other circuits.

- 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

[Jurgen Pitaske]

A slight correction:

> However, he has always used outdated processes (and I remember the
> name MOSIS, but not Globalfoundries), so it's not very likely that he
> finds problems and solutions that make a difference for a lot of other
> products.

These were not outdated processes of MOSIS at the time.
Chuck had to use processes that he could afford
and that were available for the way he generated the GDSII.

He had simulated what comes out,
so, the process selected by Chuck was suitable and good enough for his prototypes.

See Wikipedia https://en.wikipedia.org/wiki/MOSIS
It seems that the MOSIS Website is dead now,
So any new Greenarrays chips would need a new set of masks to be paid for at a new suitable fab.

Hopefully, GA still has sufficient wafers and dies to bridge the gap until the new version comes out - whenever this might be.
No dates for availability on the GA website.

[Jurgen Pitaske]

Just to add to the timeline:
https://news.ycombinator.com/item?id=3267428
GA144, available since 2011,
and not many applications known unfortunately over the last 10 years.

[Anton Ertl]

Jurgen Pitaske <jpit...@gmail.com> writes:
>On Saturday, 21 August 2021 at 09:14:25 UTC+1, Anton Ertl wrote:
>> However, he has always used outdated processes (and I remember the
>> name MOSIS, but not Globalfoundries), so it's not very likely that he
>> finds problems and solutions that make a difference for a lot of other
>> products.
>
>These were not outdated processes of MOSIS at the time.

They were many generations behind the leading edge. Such processes
are usually used for existing, working designs (designed at a time
when the process was leading edge or close to it), not for new
designs, so whatever he found out about the process did not help many
others.

>Chuck had to use processes that he could afford
>and that were available for the way he generated the GDSII.

This may explain, but does not contradict what I wrote.

>See Wikipedia https://en.wikipedia.org/wiki/MOSIS
>It seems that the MOSIS Website is dead now,

Works for me, albeit only with JavaScript. They seem to no longer do
their own manufacturing (if they ever did; I used to think so), but
currently serve as an intermediary to the big foundries TSMC and
Globalfoundries; it seems that you can still get very old processes
from these foundries. MOSIS offers TSMC 350nm; to give you an idea
how outdated that is: the Pentium Pro (1995) was manufactured in a
350nm process. There obviously still are circuits manufactured in
that process (otherwise the line would have been shut down), but not
new designs.

[Jurgen Pitaske]

I am sorry, but your informationn about processes needs some updating I assume.
Processes are there to be used.
If not relevant anymore - they stop to be available.
Chuck had to use what he could afford. And the latest processes where out of reach.
And the volumes ordered did not justify it anyway.

> >Chuck had to use processes that he could afford
> >and that were available for the way he generated the GDSII.
> This may explain, but does not contradict what I wrote.

What you wrote is incorrect and does not change if you introduce a maybe.

If it works your way,
there will be only one latest process per foundty, and everybody can basically throw away the masks with the first delivery,
as it will be superseeded with a newer process when you order next time.
This is not software - this is silicon.

And regarding 350nm - you are basically proving my point - contradicting yours.

[Jurgen Pitaske]

It makes an interesting comparison of 2 people who did Forth Processors:

On one side there is Charles H. Moore, who did it all,
including the 144 CPU GA144.

Design system: own and unchecked by others to verify quality
Commercial impact: not known
Applications: not known
Volumes sold: not known
Products manufactured:not known

On the other hand there is Bernd Paysan,
who released the b16 Code at about the same time,
and the Code made available on the Internet
This is not really comparable, but another Forth processor;

Design System: Standard supplier design tools for chip design
Commercial impact: b16 definitely used in commercial volume products
Applications: Seems to be battery control
Volumes sold: must be about 10 000 to 100 000 at least, otherwise not commercially viable

We can only hope,
that the processor IP was paid for well
and is still now,
as there were 2 processor versions used in these commercial applications
according to the Internet, commented by Bernd himself:
https://comp.lang.forth.narkive.com/89qfT2c3/msl16-fpga-forth-processors

[S Jack]

On Friday, August 20, 2021 at 5:31:22 PM UTC-5, Brad Eckert wrote:
our past. The things Chuck tried to warn us about. Isn't the point of computing to move beyond the structures of the past? Isn't that why he left Forth Inc? Everyone wanted to canonize their

"Standards are a big impediment in the evolution of Forth into Super Forth."
-- Nietzsche

[Anton Ertl]

Jurgen Pitaske <jpit...@gmail.com> writes:
>On the other hand there is Bernd Paysan,
>who released the b16 Code at about the same time,

Bernd Paysan was later. He took inspiration from Chuck Moore's
designs with 5-bit instructions (from MuP20 in 1990 to c18 in 2001).

>Design System: Standard supplier design tools for chip design
>Commercial impact: b16 definitely used in commercial volume products
>Applications: Seems to be battery control

It was used in several products from the company (or sequence of
companies as it was taken over) he worked for. One was Hi-Fi systems
for cars. Later they changed business and developed battery
controllers.

>Volumes sold: must be about 10 000 to 100 000 at least, otherwise not commercially viable

The battery controller was built into hundreds of millions, maybe
billions of smartphones and tablet computers, maybe they are still
using the b16, maybe not. The Hi-Fi application certainly had a much
smaller volume in terms of numbers of CPUs.

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> [MOSIS] They seem to no longer do their own manufacturing (if they

> ever did; I used to think so), but currently serve as an intermediary
> to the big foundries TSMC and Globalfoundries

MOSIS is an MPW (multi-project wafer) shuttle service and always has
been, afaict. It is an industry-academic consortium that makes a lot of
chips for VLSI design classes in universities, and that sort of thing.
It gathers together chip designs from multiple users, then combines the
designs onto a single wafer, gets the wafers fabbed at wherever
depending on the process, deals with cutting up and packaging the chips
etc.

I don't know whether MOSIS is US-only. cmp.imag.fr is another service
like that, based in France. They have lots of processes available
including some relatively advanced ones.

Google will now do something like this for free for FOSS projects. I
don't remember the specifics. But if you want to make a Forth chip,
here is your chance. Some more info:

https://www.theregister.com/2020/07/03/open_chip_hardware/

[Rick C]

On Friday, August 20, 2021 at 2:46:09 PM UTC-4, Brad Eckert wrote:
> On Tuesday, August 17, 2021 at 5:32:21 AM UTC-7, gnuarm.del...@gmail.com wrote:
> > I believe that much static RAM would consume a fair amount of current. In devices like this power consumption is typically an important detail to control. So it would be useful to learn what the device actually is using.
> That's an interesting thought, but it seems like being performance-oriented they aren't running off batteries. But isn't this a loaded question? Otherwise, why would you start off your response with a non-issue?

Sorry, I have no idea what you are referring to as "a loaded question". Power consumption is not purely an issue when running from batteries. Heat dissipation can also be important. I know much of today's more advanced electronics consider power consumption even when plugged in. Otherwise desktop computing would have been in the kW range by now.

> > "Modern" processors aren't designed to run Forth apps and vice versa. Isn't that the issue being addressed by such chips?
> They are designed to run apps. Apps are CPU coupled to memory. I would imagine "the issue" being addressed has to do with the C programming model.
> Maybe they are philosophically opposed to RISC's overhead of nested calls. Of course, saving every return address to the stack isn't cheap. Having stacks in memory, definitely not cheap.

Sorry, not following this thought.

> But isn't this a language problem? Now we are penalizing factoring?
> > ADC, DAC and other analog I/Os as well as the many digital peripherals... that's a big part of the reason. There's a lot of IP amortized in such off the shelf MCUs, not to mention the large code base and tool sets. Even when building a custom chip it is not very common to roll your own CPU to put in it. There has to be a compelling case to support such an investment.
> I would characterize that as an investment in our youth. Of course, there is the sunk cost problem. But, Google (why does it have to be them?) found a way around some of that. eFabless gives your kids (or your inner kid) a playground to just do interesting things in.

Sorry, not following your logic. Creating a new MCU is not inexpensive even ignoring the cost of spinning silicon. An CPU and all the peripherals around it are IP that must be developed, debugged, documented and verified before anyone builds a single chip. It is only the more advanced processes that require significant investment in the actual silicon fabrication.

I don't see how sunk cost enters into the issue unless you have already designed a CPU and surrounding IP and are throwing that away.

> > Not to be snide, but I wasn't aware that GreenArrays proved much of anything with the GA144 except that a CPU chip could be designed that sounded so good and was nearly completely ignored by anyone building products. It is one of the most unrealistic CPUs ever conceived, worse than the RCA 1802 COSMAC. As odd as it was, it has found a home in the space community... somehow.
> Isn't this about where you are personally? Chuck Moore did in fact greatly enrich GlobalFoundries by fixing their broken fab models when it really mattered. The benefits to humanity of Chuck Moore are profound. That is a life well-lived.

Sorry? Are you suggesting the design and fabrication of the GA144 was a charity effort to improve someone's tools for a fab?

Chuck Moore's life achievements should not be conflated with the company GreenArrays. GA has accomplished very little unless there have been advances that I am not aware of.

I'm glad GA built the chip. I just wish they had actually considered a market and attempted to design the chip to address one. The GA144 is a very interesting device, but it was an effort based on the idea of, "build it and they will buy", but they didn't. It got some press at the time and then faded into obscurity.

--

Rick C.

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

[Fourthy Forth]

On Monday, 23 August 2021 at 1:55:25 pm UTC+10, gnuarm.del...@gmail.com wrote:
> On Friday, August 20, 2021 at 2:46:09 PM UTC-4, Brad Eckert wrote:
> > On Tuesday, August 17, 2021 at 5:32:21 AM UTC-7, gnuarm.del...@gmail.com wrote:
> > > I believe that much static RAM would consume a fair amount of current. In devices like this power consumption is typically an important detail to control. So it would be useful to learn what the device actually is using.
> > That's an interesting thought, but it seems like being performance-oriented they aren't running off batteries. But isn't this a loaded question? Otherwise, why would you start off your response with a non-issue?

Parasitic memory, capacitance of surface, vlong refresh, high speed, not many transistors, Mr Moore not want to use. He know this, but Ga not do it. Descent size, take up as much as 144 processors. 144 go,1000 new process, big memory, standard outside memory. 144 like little boy, who think it can melt snow, but very small, very could boy, with little pee. 1000 advanced processors, with big memory, like Firetruck, very cold, loose little water, then hose snow. Done.

> Sorry, I have no idea what you are referring to as "a loaded question". Power consumption is not purely an issue when running from batteries. Heat dissipation can also be important. I know much of today's more advanced electronics consider power consumption even when plugged in. Otherwise desktop computing would have been in the kW range by now.
> > > "Modern" processors aren't designed to run Forth apps and vice versa. Isn't that the issue being addressed by such chips?
> > They are designed to run apps. Apps are CPU coupled to memory. I would imagine "the issue" being addressed has to do with the C programming model.
> > Maybe they are philosophically opposed to RISC's overhead of nested calls. Of course, saving every return address to the stack isn't cheap. Having stacks in memory, definitely not cheap.
> Sorry, not following this thought.
> > But isn't this a language problem? Now we are penalizing factoring?
> > > ADC, DAC and other analog I/Os as well as the many digital peripherals... that's a big part of the reason. There's a lot of IP amortized in such off the shelf MCUs, not to mention the large code base and tool sets. Even when building a custom chip it is not very common to roll your own CPU to put in it. There has to be a compelling case to support such an investment.
> > I would characterize that as an investment in our youth. Of course, there is the sunk cost problem. But, Google (why does it have to be them?) found a way around some of that. eFabless gives your kids (or your inner kid) a playground to just do interesting things in.
> Sorry, not following your logic. Creating a new MCU is not inexpensive even ignoring the cost of spinning silicon. An CPU and all the peripherals around it are IP that must be developed, debugged, documented and verified before anyone builds a single chip. It is only the more advanced processes that require significant investment in the actual silicon fabrication.
>
> I don't see how sunk cost enters into the issue unless you have already designed a CPU and surrounding IP and are throwing that away.
> > > Not to be snide, but I wasn't aware that GreenArrays proved much of anything with the GA144 except that a CPU chip could be designed that sounded so good and was nearly completely ignored by anyone building products. It is one of the most unrealistic CPUs ever conceived, worse than the RCA 1802 COSMAC. As odd as it was, it has found a home in the space community... somehow.
> > Isn't this about where you are personally? Chuck Moore did in fact greatly enrich GlobalFoundries by fixing their broken fab models when it really mattered. The benefits to humanity of Chuck Moore are profound. That is a life well-lived.
> Sorry? Are you suggesting the design and fabrication of the GA144 was a charity effort to improve someone's tools for a fab?
>
> Chuck Moore's life achievements should not be conflated with the company GreenArrays. GA has accomplished very little unless there have been advances that I am not aware of.

All trade secret, survive for years on paid work, could be hundreds million in one, we are not supposed to be told.

> I'm glad GA built the chip. I just wish they had actually considered a market and attempted to design the chip to address one. The GA144 is a very interesting device, but it was an effort based on the idea of, "build it and they will buy", but they didn't. It got some press at the time and then faded into obscurity.

Build what need, and they buy. Build what want and they buy. space X, but need better.

But we decide. 6Ghz chip built in France company.

[Jurgen Pitaske]

Just to add some of the successes of the good old 1802, as it was not that bad
actually the first CMOS microprocessor worldwide for low power applications especially ... :

If you could afford it, you could drive down the motorway at 150 miles per hour , enabled by the BMW Motronic - 1802 based.

And after your trip you could use your German intelligent phone based on the 1802 - won against the TMS1000.

Or if you had to call from the petrol station, why not use the 1802 based British AGI payphone. Here I actually wrote some test routines for this in addition to the technical support .

Or finding out your next flight details using the French teletext terminal using the VIS system controlled by the 1802.

All of these were just a few between 1979-1984 and in Europe that come to mind,
so there must be a lot more in Europe and the rest of the world,
like the Nordic TELMAC hobby computer
and as we probably all know - ELF.

All of these projects and additional customers needed support to understand this processor,
so I put together and published the BMP802, you find the PDF here,
http://www.exemark.com/CDP1802%20Microprocessor%20IP%20in%20VHDL.htm
and it might be soon part of my bookshelf, as I just got permission to re-publish it here
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM
42 years after the original was published in 1980.

The maker scene then was 1802 and amateur satellite systems AMSAT,
based on the 1802 and Forth,
see https://www.amazon.co.uk/gp/product/B07SGWCSKT/ref=dbs_a_def_rwt_bibl_vppi_i17.
And there was a Forth from Forth INC., to my knowledge the first Forth for Embedded Applications
and an 1802 Forth version from MPE.

And the 1802 group is still very active now as it has been for many years
https://groups.io/g/cosmacelf/message/148