3 ms·
I have a background in digital circuits and computer architecture, and I completely disagree with you that these SoC components should be run by the traditional
by pclmulqdq 4y ago
I have a background in digital circuits and computer architecture, and I completely disagree with you that these SoC components should be run by the traditional CPU cores. Most of these cores have strict latency guarantees or security boundaries that are much harder to achieve when you are trying to share silicon with the general-purpose code running on the machine, and since the cores are so small, it does not meaningfully save silicon to use them.
OSes are generally terrible at providing strict latency guarantees. If you will crash the CPU if you don't do [X] every 10 microseconds, you should not be telling the operating system to do [X]. This is the case of audio systems, radio systems, PCIe, and almost every other complicated I/O function. These could all be done with hardware state machines, but it is better (cheaper) to use a small dedicated CPU instead.
When I refer to security boundaries, a lot of people think that "security through obscurity" is the idea. It is not. It is more similar to closing all the ports on a server and applying "API security" ideas to hardware. It is a lot easier to secure a function that has a simple queue interface to the main cores than to secure a function that shares the main cores - Spectre and Meltdown have showed us that it might be impossible. Yes, these secure enclaves are used for DRM crap and other nonsense, so I can see why you might not like the existence of that core, but even if you erase the DRM software from that core and make it work for the user completely, you still will want the boundary.
Not to mention that every modern motherboard these days has a board management controller, which cannot be part of the CPU, and controls power and resets.
From a hardware perspective, these SoCs and motherboards really need to be heterogeneous systems. It's up to the system software to work with that. Heterogeneous SoCs really have nothing to do with taking power away from the user. The user can program all of these cores, but we live with abstractions that make it very hard.
- jclulow 4y agoIt's fine to have many smaller CPUs in the system, for all the purposes you state. The software that runs on them needs to be open, though, and something we can understand, fix, or even replace completely as needed. The operation of the components also needs to be documented so that it's possible to do that not just in principle but in practice. We've added several small cores of our own to the systems that make up the Oxide rack, but critically we can control them with our own (open source) software stack. The large scale host CPUs where hypervisor workloads live can communicate with those smaller cores (service processor, root of trust, etc) in constrained ways across security and responsibility based boundaries.
- pclmulqdq 4y agoIt helps a lot that you are working with server-style computing, where you can realistically do this. Things like audio and radio functions (eg bluetooth and wifi) have algorithms that are very proprietary and often patent-encumbered. The hardware architectures for radios are also similarly weird and proprietary. That kind of thing would result in a binary blob (at best) in a fully-open-source environment. Hot take: I don't mind if Dolby or a wifi chipset vendor hides their software from me as long as it has very strict definitions for its role and a very narrow I/O interface.