MESSAGE
| DATE | 2020-11-16 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [Hangout - NYLXS] I am looking for a new phone and this is what
|
On 11/16/20 9:52 AM, Ruben Safir wrote:
> https://tuxphones.com/bunnie-studios-precursor-open-hardware-risc-v-linux-pda-phone/
>
https://www.bunniestudios.com/
What is a System-on-Chip (SoC), and Why Do We Care if They are Open Source?
November 10th, 2020
Note: This post originally appeared as an update in the crowdfunding
campaign for Precursor.
Modern gadgets are typically built around a single, highly integrated
chip, known as a “System on Chip” (SoC). While the earliest home
computer motherboards consisted of around a hundred chips, Moore’s Law
pushed that down to just a handful of chips by the time 80286 PC/AT
clones were mainstream, and the industry has never looked back. Now, a
typical SoC integrates a CPU core complex, plus dozens of peripherals,
including analog, RF, and power functions; there are even “System in
Package” solutions available that package the SoC, RAM, and sometimes
even the FLASH die into a single plastic package.
Modern SoCs are exceedingly complex. The “full user’s manual” for a
modern SoC is thousands of pages long, and the errata (“bug list”) – if
you’re allowed to see it – can be hundreds of pages alone. I put “full
user’s manual” in quotations because even the most open, well-documented
SoCs (such as the i.MX series from NXP) require a strict NDA to access
thousands of pages of documentation on third party Intellectual Property
(IP) blocks for functions such as video decoding, graphics acceleration,
and security. Beyond the NDA blocks, there is typically a deeper layer
of completely unpublished documentation for disused silicon, such as
peripherals that were designed-in but did not make the final cut,
internal debugging facilities, and pre-boot facilities. Many of these
disused features aren’t even well-known within the team that designed
the chip!
Disused silicon is a thing because building chips is less like snapping
together Legos, and more like a sculptor chiseling away at a marble
block: adding a circuit is much harder than deactivating a circuit.
Adding a circuit might cost around $1 million in new masks, while
delaying the project by about 70 days (at a cost of 100,000 man-hours
worth of additional wages); with proper planning, deactivating a circuit
may be as simple as a code change, or a small edit to a single mask
layer, at a cost of perhaps $10,000 and a few days (assuming wafers were
held at intermediate stages to facilitate this style of edit).
photo credit: “Man With Mallet & Chisel Bas Relief (Washington, DC)” by
takomabibelot is licensed under CC BY 2.0
Thus a typical SoC mask set starts with lots of extra features, spare
logic, and debug facilities that are chiseled away (disused) until the
final shape of the SoC emerges. As Michelangelo once said “every block
of stone has a statue inside it, and it is the task of the sculptor to
discover it,” we could say “every SoC mask set has a datasheet inside
it, and it is the task of the validation team to discover it”. Sometimes
the final chisel blow happens at boot: an errant feature may be turned
off or patched over by pre-boot code that runs even before the CPU
executes its first instruction. As a result, even the best documented
SoCs will have a non-trivial fraction of transistors that are disused
and unaccountable, theoretically invisible to end users.
From a security standpoint, the presence of such “dark matter” in SoCs
is worrisome. Forget worrying about the boot ROM or CPU microcode – the
BIST (Built in Self Test) infrastructure has everything you need to do
code injection, if you can just cajole it into the right mode.
Furthermore, SoC integrators all buy functional blocks such as DDR, PCI,
and USB from a tiny set of IP vendors. This means the same disused logic
motifs are baked into hundreds of millions of devices, even across
competing brands and dissimilar product lines. Herein lies a hazard for
an unpatchable, ecosystem-shattering security break!
Precursor sidesteps this hazard by implementing its SoC using an FPGA.
FPGAs are user-reconfigurable, drastically changing the calculus on the
cost of design errors; instead of chiseling away at a block of marble,
we are once again building with a Lego set. Of course, this flexibility
comes at a cost: an FPGA is perhaps 50x more expensive than a
feature-equivalent SoC and about 5-10x slower in absolute MHz. However,
it does mean there is no dark matter in Precursor, as every line of code
used to describe the SoC is visible for inspection. It also means if
logic bugs are found in the Precursor SoC, they can be patched with an
update. This drastically reduces the cost to iterate the SoC, making it
more economically compatible with an open source approach. In an ideal
world, the Precursor SoC design will be thoroughly vetted and audited
over the next couple of years, converging on a low-risk path toward a
tape out in fixed silicon that can reduce production costs and improve
performance all while maintaining a high standard of transparency.
LiteX: The Framework Behind Precursor’s SoC
Precursor’s SoC is built using LiteX. LiteX is a framework created by
Florent Kermarrec for defining SoCs using the Migen/MiSoC FHDL, which
itself is written in Python 3.6+. The heart of LiteX is a set of
“handlers” that will automatically adapt between bus standards and
widths. This allows designers to easily mix and match various
controllers and peripherals with Wishbone, AXI, and CSR, bus
interconnect standards. It is pretty magical to be able to glue an extra
USB debug controller into a complex SoC with just a few lines of code,
and have an entire infrastructure of bus arbiters and adapters figure
themselves out automatically in response. If you want to learn more
about LiteX and FPGAs, a great place to start is Florent’s “FPGA_101”
mini-course.
A Brief Tour of Precursor’s SoC
Above is a block diagram of Precursor’s SoC, as of October 2020. It’s
important to pay attention to the date on documentation, because an
FPGA-based SoC can and will change over time. We generally eschew
pretty, hand-drawn block diagrams like this because they are out of date
almost the day they are finished. Instead, our equivalent of a
“programmer’s manual” is dynamically generated by our CI system with
every code push, and for Rust programmers we have a tool, svd2utra that
automatically translates SVD files generated by LiteX into a Rust API
crate. With an open source FPGA-based SoC, automated CI isn’t merely
best practice, it’s essential, because small but sometimes important
patches in submodule dependencies will regularly affect your design.
cont on the website
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
