How does one train the necessary chip designers?
There's no doubt we need more chip designers. The problem is that it is so complicated now that it can't be taught effectively, with real examples. at undergraduate level.
The toolchain handles too much - students need to understand how and why the tools do what they do, first. We need to know "basic woodwork" before programming CNC machines to do it all automatically.
I just propose that simpler, earlier toolchains should be freely available - and ARM could help in this, by open-sourcing a 1990's toolchain so that it is as easy to use as LTSpice for example. The support community then grows itself.
For real actual chips, I suggest the tools are configured to produce working designs on some sort of "baby process" - like 4um design rule in polysilicon, or maybe the Sedgefield IGZO lot? [Blair's constituency, heh...] - they claim to tape-out in 24 hours not 24 weeks and with zero mask cost. (I'm not associated, never met them, link is below)
IGZO only runs at 30kHz or so - but great, you don't need $$ 20GHz scopes to debug your IC, and you can have several goes at it, make those rookie mistakes, and get it all done in one term [semester].
Apparently IGZO can make 32-bit ARM cortex cores [ https://www.nature.com/articles/s41586-021-03625-w] - these designs are big enough to introduce all sorts of necessary further constraints and hierarchical approaches. I don't think yield is so good at this level, I'd start with small well-documented 8-bit RISC cores, peripherals, to learn from their simplicity.
There's nothing like learning from the ground up, like most [all?] previous chip designers. You can then debug a design right down to bare metal - an engineer's understanding, right down to the physics.
The new skill is to take all that, to allow it to be totally automated, abstracted, and yet still keep it under control. I can't do that, and greatly respect those that somehow can.
A low cost "primer" process with primitive tools would be an excellent hands-on teaching approach, showing directly what tasks are tedious and can be automated, once fully understood.
We all started with stacking cups as toddlers and I don't think we can miss-out any of the subsequent, practical steps - we need our towers to fall down, to make real things that either really work or really don't.
Only then do we learn the value of simulation tools, test vectors, redundancy strategies, emergency reconfigurability options - that can avoid embarrassment.
Biting the hand that feeds IT
