I/O pads (and their drivers) take up a huge amount of space. For some simpler ICs their die size is determined by their Pads.

All eFabless designs for the first two years of the program were multi-project wafers with single-project chips. And they still required the management engine.

Over the past year they tried an experimental "multi-project chip" (first samples shipped 14 months ago). But the management engine was a requirement long before this happened.

GP seems to have edited their comment, but I can't edit mine (even though it is only 8 minutes old)

Tiny Tapeout is a multi-project chip not a multi-project wafer.

The comment in question said, "It's a multi-project wafer not a multi-project chip. They cut the wafer apart into individual chips. There is one project on each chip. This has been going on since the 1970s. It is a very well-understood process." There is absolutely nothing uncivil about that comment, and it clarified that we were talking about slightly different things, thus leading to a resolution of the apparent disagreement and, I think, broader perspective for both of us.

The only even slightly uncivil thing about it would be the implication that I didn't know what MPW was, but in fact that was entirely plausible and would have been an important lacuna to correct were it true.

It was an exemplary comment, and the people who flagged it so that I could not reply were being a pain in the ass for no reason.

Yeah... guaranteed after the teething issues.

My understanding is that there were problems with the whole Open PDK, and that most designs would have run into similar issues even if Caravel wasn't preventing IO configuration.

The didn't ship those early OpenMPW runs out at all, the designs where resubmitting to later runs. In a way, the incident proves the point: Caravel allowed them to quickly prove their yield for those early shuttles was essentially 0%, without needing to test the user design.

SkyWater's 130nm has been used for all (most?) of the Efabless × Google MPW (multi project wafer) runs. That PDK was open sourced as part of that initial effort.

https://www.skywatertechnology.com/first-google-sponsored-mp...

https://github.com/google/skywater-pdk

There's a bunch of other PDKs running around now too. But progress does seem to have distinctly tapered off.

Most PDKs have an NDA, but Skywater is an exception. Also, most PDKs have some software restrictions on their standard cells because they never tested them with the open-source tools, but with difficulty you can use their design rules in software like MAGIC.

"3nm Chip Fab: $15-$20 Billion"

Not infinity, so time to start saving up... lol =3

> why would you fab a digital design in 130nm instead of just programming an FPGA?

That’s an interesting concept. So an fpga implemented on a current 7nm process is more performant (clock speed and energy use) than an asic on a 130nm process? How about 40nm process? I feel like there’s a graph of intersecting lines here.

Radiation tolerance is one case. For the price of a tiny tapeout run you could count on one hand how many qualified radiation tolerant ICs you could buy. There's some sauce involved with process choices for radiation tolerance, but one of critical things to do is use large features.

IHP is excitinybut their PDK is horrible compared to major fabs like TSMC or GF. Anyone using it for products hate it.

> and why would you fab a digital design in 130nm instead of just programming an FPGA?

Because you need some analog features with your digital design.

You should really look into summaries on how deep sub-micron adds more problems as processes shrink. It's crazy that 28nm and under even work at all. They also break faster in more ways than larger, mature nodes.

Far as 130nm, I'll give you a few reasons I'd use one over a 7nm FPGA. This is a non-HW guy saying what he's heard from pro's at different times. HW people, feel free to correct me about whatever I get wrong.

1. Unit prices. If you can take the upfront cost (NRE), the per unit price will be much lower than FPGA's. You might charge plenty per unit depending on the market. This can be a source of profit.

2. Older, larger nodes are said to be better for analog. Lots of designs are mixed-signal to use analog for it's lower power, extra performance, or how it doesn't blink (no rise/fall with clock).

3. ASIC's can't be reprogrammed like FPGA's. The custom design might be more secure like Sandia Secure Processor (Score) or CHERI RISC-V. FPGA's can only do one of these except for antifuse FPGA's.

4. Larger nodes are easier to visually inspect for backdoor with cheaper, teardown hardware. Who knows what's in the FPGA's.

5. Larger nodes are easier to synthesize, P&R, and auto-inspect (eg Calibre). That means open-source tools have a better chance of working or even being developed.

6. If not too power hungry (or power is cheap), some applications can let you outperform 7nm parts with parallel use of 130nm parts which are much cheaper or highly-optimized. An example what media wanting to do distributed, massively-parallel design for doing NN training maybe with 8-bitters and on-board, analog accelerators. My inspiration, aside from old MPP clusters (eg Thinking Machines), was a wafer-scale, analog NN done before Cerebras.

7. Improved reliability in general. In trusted checkers or fault-tolerant configuration, I feel like the 130nm parts are less likely to have a double failure or fail before the 7nm nodes.

8. If there's a business case, saying you built your own hardware is cool. It might even attract talent who benefit the company in other ways.

That's off the top of my head. Again, I just read a lot of stuff on ASIC's.

On a side note, you might find eASIC's Nextreme's interesting. They're Structured ASIC's that work like FPGA's in that design gets put on something with pre-made blocks to save money. Except, instead of software programmed, some via or metal layers get customized for the routing. While that reduces NRE cost, doing the routing in hardware supposedly reduces unit prices and energy maybe with a performance boost. They used to sample chips out quickly and relatively cheaply. Also, I think Triad Semiconductor had S-ASIC's with analog stuff.

wait, does 130nm imply i can send them verilog and receive ASICs in the mail?

With the exception of the highest clock speed chips (eg Intel CPUs), clock speeds can actually be comparable. 45 nm CPUs got to 2.5 GHz, and if you tickle a 7 nm FPGA just right it can get to ~800 MHz to a GHz. Things like microcontrollers and chips that are generally less optimized than the old Intel CPUs (which were mostly drawn at the transistor level and use a speed-optimized process) are much closer in speed. A 3-stage RISC-V at 45 nm is probably also running at 400 MHz or less, and the FPGA is capable of a 3 stage RISC-V at that speed.

But yes, in general, FPGAs on certain computational tasks will need deeper pipelines or the use of parallelism. Usually, pipeline depth works. Actually, if you look at the Intel front side bus (less optimized than the core), that's about the speed you can get from a 7 nm FPGA.

The Sky130 IO pads can't go faster than 33Mhz (at least the ones in the open source PDK), and the OpenLane flow isn't yet timing driven, so anything internal isn't going to break more than 100Mhz. These aren't fast chips or fast processes, Skywater is mostly for pedagogical and niche military and research tapeouts.

Yeah, there have been a dozen different attempts to make "an FPGA, but analog". This is one of them. They all failed. You'll note the page hasn't been updated since 02006: https://web.archive.org/web/20060715013941/http://www.anadig.... Analog circuits aren't fungible the way digital circuits are.

I'm not saying it's not a worthwhile research direction, just that it hasn't borne commercially viable fruit so far, despite decades of attempts.

Thank you!

What about power consumption?

You're right. Pretty much everything is SRAM now, though. Even the MAX 10 is an SRAM FPGA with a flash-backed storage memory.