Hacker News new | ask | show | jobs
by ajross 4340 days ago
Hm... the link only talks about the CPU, but calls itself a SoC. There's a lot more than needs to go on any chip that calls itself a "SoC", and much of it is very poorly served by existing "open source" solutions:

    + DRAM
    + I2C
    + GPIO (with stuff like 3.3v, tristate outputs, pull up/down, etc...)
    + USB2 host/device
    + SD/MMC
And that's just at the very basic level. Once you get into the consumer world you need to start talking about video output, camera input, video decode and encode acceleration, programmable GPUs,...

Really the CPU is, in some sense, the most solved problem from the perspective of open source. The designs themselves may be closed IP, but the instruction sets are meticulously documented and their behavior is very standard across many vendors and ISAs.

2 comments

The peripherals you list span a wide range of complexity.

GPIO, I2C, and SD interfaces (in approximately increasing order of complexity from my point of view) are one-person jobs for the right person. I've been in charge of all the GPIO for complex mixed-signal chips several times in the past, and I could crank these out in no time. But someone who's never designed for ESD and latchup, beyond-the-rail inputs, etc., would probably find these pretty nasty.

Forget using fab-supplied GPIO; those designs are almost always much (3-5x or more) larger than they need to be, and in advanced nodes, they tend to add additional processing cost. Specifically, most fabs want to stick with per-pad snapback clamps, which are (1) big and (2) require (in processes newer than about 0.13u; you can get away without it in earlier nodes) an additional "ESD" layer to fix doping gradients so that the devices don't destroy themselves as soon as they snap back. A much better solution, for many reasons, is transient rail clamps and steering diodes. First, because diodes can handle insane amounts of current per micron of perimeter (think: easily 50 mA / um of perimeter for a diode, vs single digit mA / um for snapback devices), their layouts are more compact, and they don't require ballasting to prevent current crowding. Second, and more importantly, clamps and diodes can be simulated (and the simulations, if not correct, are at least predictable in the way they fail depending on the models the fab gives you). Snapback is effectively voodoo: design what looks like it should work, test it, and hope that some circuit you accidentally put too close to the pad doesn't change the behavior enough to cause failures.

DRAM controllers are another step up in complexity. Depending what standard you're going after, this is going to take some reasonable work.

USB2 is, in a word, hideous. A team starting fresh is looking at several person-years (or more) for a well-designed physical interface, control logic, etc.

One wonders if they can convince someone to donate designs. Come to think of it, I'd do their GPIO/ESD/latchup design for them just for the fun of it; my current employer certainly wouldn't object.

USB2 has a fairly sane external PHY specification though with lots of parts in the market. I was thinking about USB in the context of the data layer, which (to my mostly-software eyes) seems comparatively straightforward and sane.

But absent some random hackery on opencores.org, no one seems to have really put effort into doing it on an open part in a serious way.

Greetings. I use some of those aforementioned very standard CPUs and have an issue: Many tasks I use the computer for are far more security critical than performance critical I would like have someone augment a cpu design that I'm using to give it 256 bit 'pointers' which pack 64 bit start, end, and offset, and a set of fine grained permissions and special privileged instructions for modifying these pointers. This way huge classes of security vulnerabilities will be prevented by the hardware.

I won't mind if it's 10x slower— though the thousands of times slower that I'd get with a software simulation would likely be too slow to be practical.

What? You say that the chips I currently used have closed and secret designs and are not available for modification? But I thought you said that the CPU is the most solved problem from the perspective of open source??

I guess it's good that people are working on actually open CPUs so that things like http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ can be built.

And with an "actually open CPU," how does one verify that the silicon in the final package is actually what's in the design and that no "closed and secret designs" have been added by the fabricator?
You need to xray the die and confirm the designs are the same, but it doesn't guarantee that extra or bad transistors aren't inserted that leak data.

You never really know.

https://www.cl.cam.ac.uk/~sps32/ches2012-backdoor.pdf

https://www.usenix.org/legacy/event/leet08/tech/full_papers/...

http://en.wikipedia.org/wiki/Hardware_Trojan

I think from the perspective of openness and verification a simple 8-bit CPU like a 6502[1] would be ideal - there's not a lot that can hide in 3500 transistors.

[1] http://www.visual6502.org/

One solution could be to obfuscate the design when it goes to fabrication and then check the amount of time it takes to fabricate. This assumes that obfuscation is possible in logic design, and insertion of back-doors in an obfuscated design is going to be non-trivial.
Well, somewhat a solved problem if your hardware is a uniform combinatorial logic and routing mesh (E.g. a FPGA), not exactly energy efficient.

But I think this is a weird diversion: That I can't add (or pay to add) advanced security features in my CPUs even at substantial (but sane) costs is a clear reason the current closed ecosystem is inferior to an open source one.

This remains true even if even an open cpu design were not cost-effectively auditable at the hardware level, it's an orthogonal issue (and even more so— the closed cpu designs are inherently less audi-able if hardware backdoors are your concern). An open design doesn't have to be better in ever possible way to be better in some.