Hacker News new | ask | show | jobs
by ChuckMcM 2507 days ago
It is interesting that its possible to produce chips at this price for more than a short time period. Also that they are all basically PIC clones or variants speaks to the core competency of these companies is manufacturing and operational efficiency, not MCU design.

I think a fascinating experiment here would be to invest some time in an unencumbered scalable design that could be implemented very inexpensively (say less than 10K gates). Would these manufacturers pick up that design and run with it, making variants and parts that people could buy? It would get Microchip off their back (several have been sued apparently).

5 comments

> I think a fascinating experiment here would be to invest some time in an unencumbered scalable design that could be implemented very inexpensively (say less than 10K gates). Would these manufacturers pick up that design and run with it,

I have done that thought experiment many times. I have a ISA that I sketched out many years ago but never did anything with. Often, I have thought it would be a real hoot to put up a working Verilog model on Github with a public domain license just to see if I could bait somebody in China into manufacturing it for me so that I could buy it off Digi-Key :)

Of course, the CPU isn't really the value any more. One salesman for an ARM licensee said it best: "Look at the die photos from any of the ARM licensee's. We are all just selling value-added flash." And as far as that goes, it isn't the CPU that drives the part design-in decision. It is having good, bug-free, peripherals in the right mix and a reasonable tool chain.

So the "free CPU design as wild oats" idea has appeal, but it would need an LLVM back-end to go with it, at minimum, and then unencumbered Verilog for a collection of basic peripherals.

I think you should still post it to github :-). Agreed on the peripherals as well, I good set of open source peripheral models in verilog would be a useful addition to the mix.
Have you heard of opencores.org? Its been around for a long time.
Here's this experiment sort-of running:

WCH, which sells cheap mcu's(like $0.25 8051-mcu with usb/16Kflash) is working on a risc-V bluetooth mcu:

https://www.cnx-software.com/2019/02/16/wch-ch572-risc-v-mcu...

And since risc-v has versions somewhere around 5K-10K gates, well, a lower end mcu isn't far, probably.

Still, it would be interesting to think how we can get from that, to standard peripherals, and standard pinouts, used by at least 2 mcu makers. That would be interesting.

> And since risc-v has versions somewhere around 5K-10K gates, well, a lower end mcu isn't far, probably.

5-10k? Seriously? That's amazing.

Z80 had 8500. According to Wikipedia, even truly simple and bare bones 6502 had 3510 or 3218.

The Z80 had that many transistors, not gates

The CMOS rule of thumb is one gate is 4 transistors (eg a 2-input NAND). But the first Z80 was nmos, and so the equivalent count is harder to state. 3 transistors per 2 input nmos gate is a rough first order guess, but in nmos wide gates still need only a single load resistor, and designers sometimes used dynamic logic to save even more transistors.

Ohh... This is embarrassing! I work in embedded/low level and I have always thought that gate == transistor. It's really obvious in retrospect...

I stand corrected.

It's not a crazy idea, there are indeed logic types that implement some gate types with a single transistor. For example, https://en.wikipedia.org/wiki/Resistor–transistor_logic

These were more commonly used back when transistors were expensive.

Designs like the GreenArrays F18A core show that you can do dramatically more than the 6502 or Z80 did in a similar number of transistors. The J1 and J1A are free descendants. The MOStek and Zilog hackers were wizards but they were working under serious time and, in the Zilog case, compatibility constraints. We know enough to do better now.

(https://news.ycombinator.com/item?id=20688443 is on the same topic.)

(As others commented, those are transistor counts.)

Smallest irsc-v core i know: https://devhub.io/repos/kammoh-picorv32

~1000 Luts. 1 Lut = 6-24 gates on average. a bit pmore but still pretty close.

A LUT can be 10 gates and it can be 100+ gates. You just can't compare FPGA LUTs to gates like that.

FPGAs have things like block RAMs and multipliers. Those require a ton of gates, but don't increase required FPGA LUT count by much.

Chips inspired by Chuck Moore's designs would fit this niche.
I would think a lot of manufacturers are looking to RISC-V for that kind of eventuality. But in the meantime, and looking at that chart, it seems a lot more convenient to just rip off the PIC.
I don't think they are "ripping off the PIC", I think they are reimplimenting the PIC ISA, just like 8051s are reimplemented all over the place
I don't think a RISC-V would fit in this gate count niche. Just the register file for an RV32-C core is half these chips' RAM.
Yes, the PICs don't have a register file at all. They also have quite a simple instruction set, again providing gate savings, but then the size of program ROM may be a bit larger as a result.

The ALU can be a reasonable chunk of the processor size, and an 8-bit ALU is going to be much smaller than a RISCV ALU. Although I read somewhere that some of the Z80s, although an 8-bit processor, had a 4-bit ALU, and also I read somewhere that the 32-bit NIOS processor has a 16-bit ALU. But whether that's true or not ...

I designed a size optimised 16-bit MSP430 clone for small size low cost machxo3 FPGAs that used an 8-bit ALU. It a good way of keeping the number of LUTs down when optimising for size over speed.

For something like the low cost ice40 FPGAs, a PIC would probably be a very good match for those too compared to RISCV, because ice40 doesn't have distributed memory, which is what you'd like for register files (otherwise I expect one of the block RAMs would be used for the register file, and ideally you wouldn't want that to happen).

They're using long-obsolete process nodes, so they can use surplus equipment, but at the cost of power efficiency. (Yes, that obsolete.)
Could mcu's made using modern processes be as cheap ?
I don't know, but so far nobody has managed to do it. These microcontrollers aren't just cheaper than other microcontrollers. They're cheaper than most discrete transistors, cheaper than 555s, cheaper than shitty op-amps, cheaper than linear regulators, cheaper than many diodes.
The other issue is that the older nodes are more reliable. They're already matured where they understand how to make everything work right. On top of that, each process shrink introduces new challenges that can cause components to fail. The most modern nodes seem like they make everything somewhat broken coming out the door with designers building in mitigations for that. They don't last as long.

The older nodes don't seem obsolete if component reliability is a concern. All my concepts consider their potential. They're quite limited in performance, storage size, and energy, though. There's a tradeoff. Lots of companies want a cheap, reliable, simple CPU/MCU. That's where the oldest nodes shine. That said, the newest nodes are tiny enough that one might make a 2 out of 3 setup with extra error correction like Rockwell-Collins' AAMP7G CPU. Might still be pretty cheap... per unit (not development cost)... on 28nm CMOS or SOI process. Haven't seen an attempt.

I think Padauk is using 1.3-micron or something? Can't find my notes. I don't think you have to go quite that far into the stone age to get reliability, at least not for digital.

Do you have funding to do a MOSIS run or two? I wonder if we could find some.

No funding at the moment: researching on the side while working a main job. The older nodes for MOSIS were 350nm and 500nm. The fabs for these penny chips can be stone age in comparison. You're right that you don't need to go that far given the highly-reliable POWER's and Alpha's weren't built on stone-age nodes. Edit to add that, based on MHz I remember, the Alpha's were 350nm-500nm. Fits MOSIS well. :)

If you do a project, I suggest 350nm since it's the last node that you can visually inspect the resulting silicon. It's as fast as you go before you need electron microscopes and such. It's also more likely that the open tools for hardware will be able to handle such a node instead of deep sub-micron. Finally, there's old research in transistor-level optimization that might be applied to it in new, open tooling. Might let people do standard cell that inches a bit closer to performance and energy use of custom designs.

At a certain point the packaging is the biggest cost of production.