61–70 of 84 posts
Edit: give Stallman's "Right to Read" another read.
Earlier quoted context omitted.
> The masks alone are single digit millions, Ah, another reason why hardware erratas get fixed so rarely (I assume - along with retesting of course).
Yes, exactly. A lot depends on your expected volume. Essentially, masks are your fixed tooling cost for chips. You then amortize that over your full volume. It’s easier to justify another mask set to fix bugs if you are going to be selling oodles of chips and the cost ends up being negligible and much harder to justify it if the volume is low. Years ago, I was CTO at a startup when our chips came back from fab. Every…
Earlier quoted context omitted.
Digikey and Mouser do not do this. > few individuals relying on snake oil security Please don't.
VPNs for desktop users have very few security use cases since most traffic ended up being https, but they're very useful for evading geoblocks.
Earlier quoted context omitted.
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 meeti…
Yeah, true, it's all downside for them for this, basically. Still, there must be some price for which companies will let other companies use die space, but maybe that price is higher than just doing the thing yourself...
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.
Earlier quoted context omitted.
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 meeti…
I'm basically ignorant of this entire space--I have mostly worked on SaaS products--so please forgive the question if it's too naive but as (the first?) someone who has just experienced this new and rare way of bringing a design to life are there any obvious process/tooling/whatever improvements you noticed that might make it less risky (and therefore less rare)? Reading your blog posts, the crowd supply materials, X…
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.
[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...
Earlier quoted context omitted.
Yes, exactly. A lot depends on your expected volume. Essentially, masks are your fixed tooling cost for chips. You then amortize that over your full volume. It’s easier to justify another mask set to fix bugs if you are going to be selling oodles of chips and the cost ends up being negligible and much harder to justify it if the volume is low. Years ago, I was CTO at a startup when our chips came back from fab. Every…
I knew the masks were expensive, but not that they were that expensive. Of course it's all a question of total quantity you use that mask for, but still...
It's pretty exciting to see a small chip with an MMU. I wonder if it would be possible to get sel4 running on this? I'm also curious about the current draw, but I couldn't find anything?
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.
Earlier quoted context omitted.
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…
Can I ask how bad it is with lower speed I/O? Less than 20Mbaud, so RS232, RS485, CAN, USB PD/Type-C, 10base-T, ...? The transceivers are rarely integrated, do they need different processes or do they just prefer flexible I/O pins or ...?
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.
A bit sad to see another famous hacker turning to the "dark side" --- as "security chips" are a treacherous slippery slope, no matter who controls them. Just because it's "open source" doesn't mean it's a good thing. Edit: give Stallman's "Right to Read" another read.