Baochip-1x: What it is, why I'm doing it now and how it came about (opens in new tab)

If you're lucky enough to have an affiliation with certain institutions, there are programs that basically give academics the experience I had for a nominal fee. TSMC has a finfet program [3] which powers Soclabs [4] to provide an environment that exceeds Baochip's capabilities. If you look through [4] notice the block that says "Users' HW circuits" - that's basically what my logic is on Baochip. The problem with these is you need to be academic and I think there isn't a clear path to commercialization, and of course lots of NDAs. China also has a program called "One Student One Chip" [5] where students can tape out quite sophisticated SoCs as part of their course work.

It's probably just a matter of time before these academic programs yield a commercially compelling chip, and then that would pave a path for a transition program from the academic program to industry.

Another option is, if Baochip is quite successful, it in itself could serve as a "proof point" that may encourage other companies to allow hitchhikers. When the co-designed IP works, then it's a sales upside for the company, so there is some incentive alignment.

The trick is figuring out how to mitigate the possibility that the IP doesn't work, and bridging the gap between people with ideas and people with tape-out experience. I'm lucky in that in my first jobs out of college I did a deep dive into silicon, even designing custom transistor and standard cells for a bespoke nanophotonics PDK that I helped to develop, so I had the shared language to communicate with both classic chip companies and open source community.

There's an enormous cultural gap between the chip community and the open source community, but everyone's curiosity in this thread and participating in this dialog with questions like yours helps close that gap and thus manifest more hitchhiking opportunities in the future.

[1] https://tinytapeout.com/

[2] https://github.com/librelane/librelane

[3] https://www.tsmc.com/english/dedicatedFoundry/services/unive...

[4] https://soclabs.org/project/tsri-arm-cortex-m55-aiot-soc-des...

[5] https://ysyx.oscc.cc/en/project/intro.html

The open-source argument is that if we could make that back-end part more transparent, then, we could improve the tooling and thus decrease the labor. But, even a single mistake at these backend steps can scuttle a whole mask set. The methodology is incredibly incremental, scripts are handed down for generations and there are magic settings in them that make things "just work" and nobody quite remembers why or how but it was probably a lesson learned the hard way so we just leave it that way. And it's not just the money - the iteration time through a fab is months. So you have to be a bit careful about prioritizing your experiments and your risk budget when trying to make progress in this field.

I am lucky in my case because what I want to do aligns with their original commercial interests, so the strategic benefit makes things worth the tactical risk. Frankly a big part of the project overall was just figuring out how to scope things so that we both came away reasonably satisfied in terms of risk and outcomes. Would I like things to be more open? yes. would I liked to have put an opentitan core in there? yes. Would I have been able to take advantage of more back-end support to do a faster CPU? yes. But, we had to constantly balance tactical risks, and even if I don't agree with all their decisions, I have to respect their experience.

[1] https://github.com/efabless/caravel

Anyone is permitted to implement a RISC-V CPU, which would then involve coding something up in an RTL. The resulting RTL artifact may be open or closed source depending upon the developer's preference. In the case of the Vexriscv, that particular one implementation is MIT licensed. There are other implementations that also have MIT licenses, but because it is up to the core's implementer to pick a license, not all RISC-V cores are open source.

In fact, some of the most commercially successful RISC-V cores are closed source licensed.

It's a good model for MCU stuff. There were people pushing Chip Gracey (Parallax) to use RISC-V instead of his custom ISA when he designed the P2 a few years ago, but he chose to do his own thing. Which has made compiler development difficult.

So for example, many projects bitbang USB full-speed using plain old 3.3V I/Os but by the spec the signals have to have some slew rate limiting in a form that isn't found on standard I/Os. And also, if you're doing it right, you're taking the differential signals in on USB and not just reading them into two separate single-ended pads but you're actually subtracting the analog values to get the full benefit of differential signaling's common mode rejection properties. Thus even a lower speed USB PHY has some specialty circuits in it to achieve these nuances.

As another example, RS232, by the spec, would be a +/-3V to +/-15V driver, which is actually really specialized in the chip world and quite uncommon due to the negative voltages. PHYs that drive I/Os is one of the enduring pain points for open source PDKs - they are hard to develop, "boring" because they are "just wires", but absolutely essential to get right and bring into existence if you want to talk to anything interesting.