After reading the "6 GHz stack machine" thread, I would have to guess you guys are all from Silicon Valley. There's a reason Chuck moved to Yosemite. Maybe it wasn't to climb El Capitan, but why do people climb mountains? Because they are there, not because there are paying customers. Nobody is going to pay you to climb to the top of a big rock.

Nobody needs asynchronous computers just like nobody needs to scale cliffs. But the technology is there.

When Chuck started MISC, he was working with what he had. Logic delays were important in the process nodes he was targeting. He wanted to simulate transistors, so he made OKAD. I don't have OKAD, you don't have OKAD. It's okay, OKAD might not be the right tool for the job anymore.

Today, what do we really build computers out of? Standard cells and wires. Google and SkyWater put together a PDK with a library of standard cells that you can actually download and use for free. Free tools compile RTL to GDS, but aren't we trying to not use RTL? Asynchronous computers, remember? GreenArrays showed what could be done with asynchronous computers.

Chuck admitted that he couldn't build big RAMs. It turns out that RAM is tough. It was the overhang that Chuck couldn't quite get around. You need to use a RAM generator. He didn't have one of those. OpenRAM is out there, though. It was originally used with 45nm, but it is being used with the 130nm SkyWater PDK. OpenRAM is also free.

The chip design landscape has changed. Logic delays used to be more important. Now it's wire delays. Wires cause delays and power consumption. So, why simulate transistors? Why not focus on the important stuff, the wires. The map is not the territory, but the territory has changed. Now we are in wire land. Wires and standard cells. We are not building with transistors. We can simulate wire delays in Forth. Wire delays can be simulated in Verilog and VHDL too. Using Forth facilitates other functionality. For example, you could simulate power consumption. You can check for timing violations as you go.

Contrary to Chuck's experience with commercial chip design tools, you really can build asynchronous computers in a standard design flow. It doesn't have to be RTL. It should be Verilog at least to allow simulation in FPGAs. But Verilog is a bad language for processor design. It's too low-level. The processor should be described in a higher-level language and compiled to Verilog. Forth is a language for making languages, it could do the job. It could also simulate the hardware directly.

Brad, thanks for this. We are not in silicon valley. Chuck keeps moving for expenses related reasons. I think there might be some current tax advantage to where they are. Other people would have followed this better than me. I was sad he lost his custom built house, which was good for bringing a little ray of light into the world.
A lot of the computing has .over to asynchronous communications. In a way, what church offered, is very relevant, and in line with dynamic evergy reduction. I also proposed years ago, the benefits of dynamic energy consumption, and NVIDIA has moved into this deeply as well. Chuck's model, is just another version. It's not only the lowest energy chip, but lowers energy again by being asynchronous in its work load handling.

Okcad was out there for people to tinker with. But newer version and replacement might not be.

I imagine designing with transistors, is still important alongside wires. Libraries are great, but why give up. 6 transistor Stam just takes up heaps of space, but maybe 1-3 transitive parasitic ram helps. Normal CPU design is such, with so many layers, you might be able to fit
an array of processors on a 3D stack of ram, in a dozen to 50 layer process.. If you had a double sided chip you could put processor, memory, on one side and and memory on the other. The first sounds good for interprocessor communications, the send for a general memory, a main processor might have priority to over. The 3D printing technique, or using stamps, possibly allows high 3D structures. Lot's of memory. There is experimental flexibility there.

On Thursday, December 9, 2021 at 2:26:23 AM UTC+10, Brad Eckert wrote:
> After reading the "6 GHz stack machine" thread, I would have to guess you guys are all from Silicon Valley. There's a reason Chuck moved to Yosemite.. Maybe it wasn't to climb El Capitan, but why do people climb mountains? Because they are there, not because there are paying customers. Nobody is going to pay you to climb to the top of a big rock.
>
> Nobody needs asynchronous computers just like nobody needs to scale cliffs. But the technology is there.
>
> When Chuck started MISC, he was working with what he had. Logic delays were important in the process nodes he was targeting. He wanted to simulate transistors, so he made OKAD. I don't have OKAD, you don't have OKAD. It's okay, OKAD might not be the right tool for the job anymore.
>
> Today, what do we really build computers out of? Standard cells and wires.. Google and SkyWater put together a PDK with a library of standard cells that you can actually download and use for free. Free tools compile RTL to GDS, but aren't we trying to not use RTL? Asynchronous computers, remember? GreenArrays showed what could be done with asynchronous computers.
>
> Chuck admitted that he couldn't build big RAMs. It turns out that RAM is tough. It was the overhang that Chuck couldn't quite get around. You need to use a RAM generator. He didn't have one of those. OpenRAM is out there, though. It was originally used with 45nm, but it is being used with the 130nm SkyWater PDK. OpenRAM is also free.
>
> The chip design landscape has changed. Logic delays used to be more important. Now it's wire delays. Wires cause delays and power consumption. So, why simulate transistors? Why not focus on the important stuff, the wires. The map is not the territory, but the territory has changed. Now we are in wire land. Wires and standard cells. We are not building with transistors. We can simulate wire delays in Forth. Wire delays can be simulated in Verilog and VHDL too. Using Forth facilitates other functionality. For example, you could simulate power consumption. You can check for timing violations as you go.
>
> Contrary to Chuck's experience with commercial chip design tools, you really can build asynchronous computers in a standard design flow. It doesn't have to be RTL. It should be Verilog at least to allow simulation in FPGAs. But Verilog is a bad language for processor design. It's too low-level. The processor should be described in a higher-level language and compiled to Verilog. Forth is a language for making languages, it could do the job. It could also simulate the hardware directly.

My apologies. I have to stop using Google products here. It after 12 and I didn't think there was an editing issue.

Wayne morellini <waynemorellini@gmail.com> writes:
> Chuck keeps moving for expenses related reasons. I think there might
> be some current tax advantage to where they are. Other people would
> have followed this better than me. I was sad he lost his custom built
> house, which was good for bringing a little ray of light into the
> world.

I had not heard about Chuck losing his house. That is sad to hear. I
remember GA moving from Nevada to Wyoming after the Patriot(?) lawsuit
finished, since they no longer had a reason to stay in NV and they liked
WY better. I don't know what the earlier reason to stay in NV was.

> I imagine designing with transistors, is still important alongside
> wires. Libraries are great, but why give up.

It seems like premature optimization for a small company trying to make
a digital product.

Any idea what Chuck is doing now? I thought he had come out of the
settlement with a nice chunk of cash.

On 12/8/21 10:26 AM, Brad Eckert wrote:
> Now we are in wire land. Wires and standard cells. We are not building with transistors. We can simulate wire delays in Forth. Wire delays can be simulated in Verilog and VHDL too. Using Forth facilitates other functionality. For example, you could simulate power consumption. You can check for timing violations as you go.
>

If you are targeting standard cells, you might as well just use a FPGA
since there is little advantage.

Standard cells have their place but they are slower and bigger than
something designed from scratch. Many things are better from scratch:
register arrays, ALUs, RAM, etc. Control logic is one place where
standard cells are fairly useful. It tends to use less area than the
rest of the CPU and is made up of standard gates. So letting something
like Verilog or VHDL generate your control logic saves time at a
tolerable cost.

If you are going to go the route of custom silicon with its high costs,
spend a little more time up front. Otherwise, just use FPGAs.

If you want to try your hand at VLSI design, the tools that I used when
I took a VLSI design course long ago are still available. (Back then
they only ran on a SPARC workstation.) I just checked and magic and
irsim are still in the Fedora repositories. With those you can lay out
and simulate your design.

For example:
http://davesrocketworks.com/electronics/1802/control/johnson/index.html

--
http://davesrocketworks.com
David Schultz

On Friday, December 10, 2021 at 3:04:56 PM UTC-5, David Schultz wrote:
> On 12/8/21 10:26 AM, Brad Eckert wrote:
> > Now we are in wire land. Wires and standard cells. We are not building with transistors. We can simulate wire delays in Forth. Wire delays can be simulated in Verilog and VHDL too. Using Forth facilitates other functionality. For example, you could simulate power consumption. You can check for timing violations as you go.
> >
> If you are targeting standard cells, you might as well just use a FPGA
> since there is little advantage.
>
> Standard cells have their place but they are slower and bigger than
> something designed from scratch. Many things are better from scratch:
> register arrays, ALUs, RAM, etc. Control logic is one place where
> standard cells are fairly useful. It tends to use less area than the
> rest of the CPU and is made up of standard gates. So letting something
> like Verilog or VHDL generate your control logic saves time at a
> tolerable cost.
>
>
> If you are going to go the route of custom silicon with its high costs,
> spend a little more time up front. Otherwise, just use FPGAs.
>
>
> If you want to try your hand at VLSI design, the tools that I used when
> I took a VLSI design course long ago are still available. (Back then
> they only ran on a SPARC workstation.) I just checked and magic and
> irsim are still in the Fedora repositories. With those you can lay out
> and simulate your design.
>
> For example:
> http://davesrocketworks.com/electronics/1802/control/johnson/index.html

Why would RAM be better designed from scratch? It is nearly a primitive element itself consisting of very little repeated many times. That is ideal for a basic element in any sort of ASIC. Maybe I'm not grasping what you are saying?

--

Rick C.

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

On 12/10/21 4:00 PM, Rick C wrote:
> Why would RAM be better designed from scratch? It is nearly a primitive element itself consisting of very little repeated many times. That is ideal for a basic element in any sort of ASIC. Maybe I'm not grasping what you are saying?
>

Maybe you are expecting a RAM standard cell instead of constructing a
RAM from standard cells.

--
http://davesrocketworks.com
David Schultz

On Saturday, December 11, 2021 at 5:01:27 AM UTC+10, Paul Rubin wrote:
> Wayne morellini <waynemo...@gmail.com> writes:
> > Chuck keeps moving for expenses related reasons. I think there might
> > be some current tax advantage to where they are. Other people would
> > have followed this better than me. I was sad he lost his custom built
> > house, which was good for bringing a little ray of light into the
> > world.
> I had not heard about Chuck losing his house. That is sad to hear. I
> remember GA moving from Nevada to Wyoming after the Patriot(?) lawsuit
> finished, since they no longer had a reason to stay in NV and they liked
> WY better. I don't know what the earlier reason to stay in NV was.
> > I imagine designing with transistors, is still important alongside
> > wires. Libraries are great, but why give up.
> It seems like premature optimization for a small company trying to make
> a digital product.
>
> Any idea what Chuck is doing now? I thought he had come out of the
> settlement with a nice chunk of cash.

I have not kept up for many years. My memory is very scratchy in parts, due to an physical illness. As you might have read, I was dying of it. That's what I remember, he had to give up and leave. That there were advantages to moves. That's before, it's now about what happens. People have opinions here, and I'm not saying a lot aren't ready but, but it gets a bit hard to say things around here.

On Saturday, December 11, 2021 at 8:36:18 AM UTC+10, David Schultz wrote:
> On 12/10/21 4:00 PM, Rick C wrote:
> > Why would RAM be better designed from scratch? It is nearly a primitive element itself consisting of very little repeated many times. That is ideal for a basic element in any sort of ASIC. Maybe I'm not grasping what you are saying?
> >
> Maybe you are expecting a RAM standard cell instead of constructing a
> RAM from standard cells.
> --
> http://davesrocketworks.com
> David Schultz

Dram are specialised processes, with too few layers for a standard CPU, and hard to access. I suggested that their CPU might fit on a dram process, due to its simplicity. There are bandwidth and timing advantages. I don't know if commodity dram processing chips ever got anywhere, due to these reasons, which suite more server operations instead of gpu or CPU etc. However, something they could have tested on their runs, was memory that uses substrate capacitance affects to at as memory, requiring one of more transistors. As far as I know, this can be tested on asic standard processes. So, you slip a few transistors on each test run, and see if any work. I don't remember, but maybe this was proposed in a period that overlaps the 180 period. It was after transistor on insulator was introduced.

Here is a paper that covers one form of this, zero capacitance ram, magneto and thyristor ram:

http://meseec.ce.rit.edu/551-projects/fall2016/1-3.pdf