@mxk @Xobs@mastodon.socia

To give some background, I "hitchhiked" my functions on another tape-out that was paid for by a company called Crossbar Inc. Crossbar took the unusual step of agreeing to open source all the RTL they were legally allowed to, and they held up to that agreement.

Thus from the get-go, I was not the architect of the chip, but rather, a guest on someone else's chip. I could politely advise, but not dictate the terms of the cores.

Here's the what:

The components that aren't open sourced are the foundry IP (analog + detailed memory models + USB), the AMBA bus framework, plus a couple small blocks (RTC, MDMA) that I didn't have a say in and are not required for normal operation.

Here's the why:

Foundry IP models (analog+memory) are quite difficult to open source and considered to be out of scope for this project. There's people working on it, but at the moment there are no processes smaller than 130nm that have open source IP. To give some context, at 130nm you might be able to do a chip that runs at dozens of MHz with a few dozen kilobytes of RAM. In contrast, Baochip runs at 350/700MHz with a couple megabytes of RAM.

USB/AMBA models were picked for their maturity. The open-source alternatives didn't provide the same feature set or validation quality. Eventually such IP can be brought up to standard but one has to allocate risk strategically; if the chip doesn't boot because of a bus framework bug, then you have no chip at all.

For the blocks I was directly responsible for, I picked a fully open source bus framework. The framework did turn out to have several subtle bugs, which took a lot of effort to rectify (open source comes with no warranty, so all the testing falls on your shoulders!).

One bug unfortunately made it through to the final silicon and requires a less than desirable work-around (the chip has to reboot itself once to get a clock domain synchronizer into a reliable state; end users barely notice it because it's quite fast, but this is only possible because the main CPU boot is reliable). So in the end, Crossbar's choice to insist on a battle-proven bus framework was prescient: the chip probably wouldn't have worked at all if we went with the fully open source framework on the first go around.

The other small blocks were mostly last-minute add-ons and we didn't have the time/resources to qualify open source versions and we already had off-the-shelf, tape-out proven, closed-source versions. There was only one of me involved in the tape out, versus dozens of engineers on their end, and the schedule was fixed by their needs.

The Crossbar version of the chip also has a Cortex-M7 in it - they viewed it too risky to go with a pure open source core, and I respect that opinion - but their CPU is fused off in my version of the chip, so it is dead silicon.

Basically, the question is equivalent to "how come you didn't boil the ocean in a single kettle", and the answer is "the kettle isn't big enough, so we have to boil it one kettle at a time".

As to which kettles were picked to boil: all the blocks that can perform a computation on my version of the chip are open source.

The remaining blocks can either be verified to be working correctly by e.g. read/write tests (fill the memory with random values, read back & compare; the existence of "shadow" memory can be disproven with IRIS), or they can't affect computation (eg analog blocks), or they should just be passing data around without modification (eg bus frameworks).

This approach does not disprove the existence of malicious code buried somewhere in the closed source blocks, but it does say you can inspect all the blocks that we say *should* be doing computation and you can confirm their function. It's a "better-than-nothing" approach, and it enables some pretty neat stuff in terms of simulating the chip to develop/debug firmware.

I understand this approach will disappoint those who want the highest bar cleared on the first try. To those who disapprove: it's open source, please jump in and help clear the bar!

But, let's consider that we can raise the bar now, so why not raise it? We don't have to settle for fully closed source solutions, so long as incremental progress is considered acceptable.