bunnie

Just another +1 for fastmail, long time user, really pleased with the service. They do one thing and they do it well, and they charge a fair price for the value delivered.

Actually this chip does have ECC on many of the SRAMs - hence the bit widths of 36 bits instead of 32 in many cases. If it's a concern that the ECC is being used as storage, I'd suggest a laser glitch on the SRAMs to confirm the disturbance is caught by the ECC logic. This would at least confirm that the ECC bits are being used as some form of ECC. We've done testing to confirm the ECC function, but you don't have to take my word for it, it's a thing you can verify, too.

This check would not rule out the possibility that maybe there is some further back door that perhaps at runtime turns off the ECC function and then starts using the bits as storage, but one would need to hide the trigger for this somewhere, and there would need to be a non-trivial amount of logic to perform multiple accesses to the RAM to stripe e.g. executable code across the ECC bits. Specifically, you'd have to do 8 reads to put together a single 32-bit word in the case of a 36-bit wide RAM, which creates a fairly sizeable timing and power side channel.

If the ECC is confirmed (via glitch or sidechannel) during the trusted-boot measurement phase, and all the code and data space is accounted for, then the alternate mode trigger would then have to be in hardware. In either case there would be a non-trivial logic disturbance in the surrounding gates compared to the reference design (this is assuming you're trying to differentiate between a "good" design and a "modified" design).

To be clear, the article states that optical inspection alone can not yield a perfect security bound. However, it reduces the attack surface from an essentially unbounded problem, to a set of more difficult attacks such as the ones outlined above, which once enumerated can be detectable via other means.

This is a much stronger bounds than chips that are impossible to visibly inspect, and thus can trivially hold several kilobytes of fast code storage that can be easily swapped out and run at full speed, leaving little to no side channel to detect, and an intractably large space to search via software-only brute force for discovery.

Re: repair rows - these are a valid place to hide data, but in this design there are no repair rows, and you can confirm they don't exist from the imaging data.

I've run power for a 100-person theme camp in the past. According to the logs, we burned an average of 36.8 gallons per day, or 1.4 liters/person/day (we ran the generator for 9 days total) in 2025. The camp has air conditioners (iirc ~20 units), lighting, freezers, etc. although not everyone has all of the above.

The average household consumption of electricity per day in the US is about 28kWh, which would take around 7-9 liters/day of diesel. Assuming an average US household of 2.6 persons, that's about 3 liters/person/day for electricity alone - does not include gas/electricity spent driving. So, at least for this camp, the average person is using less electricity at the burn, than if we weren't at burning man.

The fossil fuels spent getting to and from the event are more substantial than those burned at the event, but this is a separate discussion I think as to whether or not people should be flying to conferences, events, or taking vacations. COVID was great for reducing travel-related fossil fuel consumption, so we have the data and the experience on how to reduce that, but probably not the will.

The power logs are pretty interesting to look at. On average the generator is lightly loaded, so a lot of energy is going towards idling the generator, but batteries are expensive and these generators are not made to be stopped and started repeatedly.

Anecdotally, from when I did first amendment activism, my lawyers would always recommend that I stick to doing it with dead tree editions as much as possible. Literal book banning and/or burning has direct judicial precedent that is hard to contest, enforced by lots of precedent.

The problem with moving out of the dead tree medium is that suddenly a whole host of alternative, untested legal theories can be thrown at you. Even if they are preposterous or 'obviously wrong' to the lay person, these alternative theories increase the cost of litigation, and limits the quick remedies you can seek, because the judge has to consider now if your situation is different from precedent.

If your adversary is well funded they can just keep on throwing up 'but what about...' theories to the court for years and years, effectively achieving censorship without setting any meaningful legal precedent.

Then they can reuse this strategy again and again, and anytime a litigant gets close to winning they settle out of court, avoiding clear legal precedent and thus preserving this 'legal purgatory' path (settlements do not create legal precedent).

Basically, they learned from experience with books how to avoid other media getting the same level of effective legal protection.

It's a clever exploit on the legal system, but not great for actual justice.

The core ID definitely didn't need to be in a register, but the elapsed clocks since reset is actually really handy. Having this in the hot path allows me to build a captouch sensor using the BIO, because the clock increment is 1.42ns and even though the rise time of the pad is microseconds you get plenty of resolution at that counting rate.

I think it will be interesting to see what people end up doing with it and what are the pain points. As you say, it's a v1 - with any luck there will be a v2, so we could consider the time starting now as a deliberation period for what goes into v2.

The good news is that it also all compiles into an FPGA, so proposed patches can be tested & vetted in hardware, albeit at a much slower clock rate.

Yah, it is - the text is first posted to the campaign, and then copied to my blog for long-term archival in a domain that I control, sans the sales pitch.

It's hard to know for sure, because we don't have access to the PIO's implementation, but I suspect that the PIO is "not small".

That being said - size isn't everything. At these small geometries you have gates to burn, and having access to multiple shifts in a single cycle really do help in a range of serialization tasks.

I suspect there are tricks to get higher rates, for sure. And hopefully once we see a library of applications forming, we can make informed decisions about what extensions and features would be necessary to enable the next level of I/O performance.

USB 12Mbps is one of the envisioned core use cases - the Baochip doesn't have a host USB interface, so being able to emulate a full-speed USB host with a BIO core opens the possibility of things like having a keyboard that you can plug into the device. CAN is another big use case, once there is a CAN bus emulator there's a bunch of things you can do. Another one is 10/100Mbit ethernet - it's not fast - but good for extremely long runs (think repeaters for lighting protocols across building-scale deployments).

When considering the space of possibilities, I focused on applications that I could see there being actual product sold that rely upon the feature. The problem with DVI is that while it's a super-clever demo, I don't see volume products going to market relying upon that feature. The moment you connect to an external monitor, you're going to want an external DRAM chip to run the sorts of applications that effectively utilize all those pixels. I could be wrong and mis-judged the utility of the demo but if you do the analysis on the bandwidth and RAM available in the Baochip, I feel that you could do a retro-gaming emulator with the chip, but you wouldn't, for example, be replacing a video kiosk with the chip. Running DOOM on a TV would be cool, but also, you're not going to sell a video game kit that just runs DOOM and nothing else.

The good news is there's plenty of room to improve the performance of the BIO. If adoption is robust for the core, I can make the argument to the company that's paying for the tape-outs to give me actual back-end resources and I can upgrade the cores to something more capable, while improving the DMA bandwidth, allowing us to chase higher system frequencies. But realistically, I don't see us ever reaching a point where, for example, we're bit-banging USB high speed at 480Mbps - if not simply because the I/Os aren't full-swing 3.3V at that point in time.

FIFO is 8-deep. I did fail to mention that explicitly in the article, I think. The depth is so automatic to me that I forget other people don't know it.

The deadlock possibilities with the FIFO are real. It is possible to check the "fullness" of a FIFO using the built-in event subsystem, which allows some amount of non-blocking backpressure to be had, but it does incur more instruction overhead.

Correct, actually most programs I've written for the BIO are in assembly.

The C compiler support is a relatively recent addition, mostly to showcase the possibilities of doing high-level protocol offloading into the BIO, and the tooling benefits of sticking with a "standard" instruction set.

If there's a single rising edge on the bus that you can use as quantum trigger, then, the reads turn into as series of moves into a FIFO, and the response can be quite fast. The quantum-trigger-on-GPIO was provided to solve exactly the problem you described.

It depends a lot upon where the processing is happening. For example, you could do something where all the data is pre-processed and you're just blasting bits into a GPIO register with a pair of move instructions. In which case you could get north of 60MHz, but I think that's sort of cheating - you'll run out of pre-processed data pretty quickly, and then you have to take a delay to generate more data.

The 25MHz number I cite as the performance expectation is "relaxed": I don't want to set unrealistic expectations on the core's performance, because I want everyone to have fun and be happy coding for it - even relatively new programmers.

However, with a combination of overclocking and optimization, higher speeds are definitely on the horizon. Someone on the Baochip Discord thought up a clever trick I hadn't considered that could potentially get toggle rates into the hundreds of MHz's. So, there's likely a lot to be discovered about the core that I don't even know about, once it gets into the hands of more people.

As a side note about speed comparisons - please keep in mind the faster speeds cited for the PIO are achieved through overclocking.

The BIO should also be able to overclock. It won't overclock as well as the PIO, for sure - the PIO stores its code in flip-flops, which performance scales very well with elevated voltages. The BIO uses a RAM macro, which is essentially an analog part at its heart, and responds differently to higher voltages.

That being said, I'm pretty confident that the BIO can run at 800MHz for most cases. However, as the manufacturer I have to be careful about frequency claims. Users can claim a warranty return on a BIO that fails to run at 700MHz, but you can't do the same for one that fails to run at 800MHz - thus whenever I cite the performance of the BIO, I always stick it at the number that's explicitly tested and guaranteed by the manufacturing process, that is, 700MHz.

Third-party overclockers can do whatever they want to the chip - of course, at that point, the warranty is voided!

Agreed! The PIO is great at what it does. I drew a lot of inspiration from it.

The idea of the wait-to-quantum register is that it gets you out of cycle-counting hell at the expense of sacrificing a few cycles as rounding errors. But yes, for maximum performance you would be back to cycle counting.

That being said - one nice thing about the BIO being open source is you can run the verilog design in Verilator. The simulation shows exactly how many cycles are being used, and for what. So for very tight situations, the open source RTL nature of the design opens up a new set of tools that were previously unavailable to coders. You can see an example of what it looks like here: https://baochip.github.io/baochip-1x/ch00-00-rtl-overview.ht...

Of course, there's a learning curve to all new tools, and Verilator has a pretty steep curve in particular. But, I hope people give the Verilator simulations a try. It's kind of neat just to be able to poke around inside a CPU and see what it's thinking!

Actually, the PIO does what it does very well! There is no "worse" or "better" - just different.

Because it does what it does so well, I use the PIO as the design study comparison point. This requires taking a critical view of its architecture. Such a review doesn't mean its design is bad - but we try to take it apart and see what we can learn from it. In the end, there are many things the PIO can do that the BIO can't do, and vice-versa. For example, the BIO can't do the PIO's trick of bit-banging DVI video signals; but, the PIO isn't going to be able to protocol processing either.

In terms of area, the larger area numbers hold for both an ASIC flow as well as the FPGA flow. I ran the design through both sets of tools with the same settings, and the results are comparable. However, it's easier to share the FPGA results because the FPGA tools are NDA-free and everyone can replicate it.

That being said, I also acknowledge in the article that it's likely there are clever optimizations in the design of the actual PIO that I did not implement. Still, barrel shifters are a fairly expensive piece of hardware whether in FPGA or in ASIC, and the PIO requires several of them, whereas the BIO only has one. The upshot is that the PIO can do multiple bit-shifts in a single clock cycle, whereas the BIO requires several cycles to do the same amount of bit-shifting. Again, neither good or bad - just different trade-offs.

Hello again HN, I'm bunnie! Unfortunately, time zones strike again...I'll check back when I can, and respond to your questions.

To clarify - RISC-V is an architecture, and that is an open specification. However, as an architecture it only specifies things like, what the instructions are and their encodings. It doesn't actually give you a CPU that does anything, just an abstraction of how to describe a CPU to a common standard.

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.

Hmm...it's not just the speed. Actually, the I/O pads themselves are closed source because there's a lot of process magic in them - from the ring seals to the ESD protection, the foundries consider these to be part of what makes them different from each other, so they protect those designs.

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.

thank you~~

I imagine sel4 could be possible, but I haven't done any specific checking for compatibility.

Current draw - depends on the operating mode, etc. A dabao board with all its regulators and overhead draws around 30mA @ 5V. The CPU in "WFI sleep" (clocked stopped, instant wake-up, all memory preserved) will draw about 12mA @ 0.85V. There's a "deep sleep" mode that requires an effective reboot (clock stopped, no memory preserved) to come out of where it's down to under 1mA @ 0.7V. These latter low power modes require an external power management architecture that can vary the voltage of the core so you can achieve lower leakage states.

I think comparatively speaking, the Baochip doesn't have strong low power numbers. I have always imagined it as more of a chip that gets stuck into a USB device, so it's plugged into a host with a fairly ample power reserve, and not a coin cell battery.

It all depends on the node. Masks in 130nm are maybe in the $10k's-$100k's range. Masks for the latest TSMC nodes might cost you $30-40 million per set. The masks are pretty much a modern marvel in their own right - I'd wager they are some of the most precisely manufactured human objects in existence.

There's actually a whole space of shared-mask tapeouts. You might have heard of TinyTapeout [1]/LibreLane [2] and the general concept of "MPW" masks - multi-project wafer masks. These effectively share cost among hundreds of developers, bringing the cost of a tape-out down.

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

In the space of possibilities this can be abstractly thought of as a Caravell [1] harness gone wild. But if you had to price access to the project in a commercial sense, then, the pricing is going to be quite high. Because it's not just the cost of the masks - there's a whole lot of talent and skill in the team that does the "backend" processing. That is, once the RTL is done, it goes through multiple passes of place/route/timing, ATPG, DRC, LVS...and that's just to get to the tape-out. After that there's still more to do with the chip probe, packaging and reeling.

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

Thank you for sharing! Comments like this make all the effort worthwhile. <3

<3 makes all the effort worth it to hear stories like this. Thanks for sharing!

Crossbar is unusual to start with in that they wanted to do open RTL - so for starters, there's to a first order no companies even willing to discuss open RTL designs. Beyond that - mainly risk. I had to pinky swear that whatever I added would not break the chip, cause timing closure issues, delay the schedule, consume too much area or power, impact yield, I had to run my own validation and review program while meeting their dev methodology, etc. etc. I had to exercise an enormous amount of self-restraint to not push harder and do more interesting things as it was. It's very hard to build up inter-personal trust, and they had to take a calculated risk letting a schmuck like me potentially foul up a multi-million dollar mask set. Hats off to them for making that bold decision, it would have been easier to say nope, too risky, no benefit, cut it from the code base.

In general, things that are not strictly digital (PHYs, regulators, PLLs, ADCs) contain significant amounts of foundry IP that would be hard to release as open source. But also, some parts of the chip, for example the AXI bus fabric, were licensed simply as a risk reduction measure. If the bus fabric is bad, you've wasted millions of dollars on a mask set with little recourse. I tried to pull in some open source AXI fabrics and it wasn't pretty...a lot of rework required and even then still some bugs made it through to tape-out. Over time more and more of this can be opened but it all takes time, money, and people willing to do it.

The chip comes from the factory with a boot0/boot1 chain that is fully reproducible and buildable from source. Developers can replace boot1 with their own version, where you could add the feature you're thinking about.