Fork in the Node: Exploring Compute Node Spinoffs

Introduction

In one of our past articles, we explored our standard’s potential as a retro PC platform. In it, we mentioned an FPGA-based node that would likely be incompatible with our standard. That got us thinking about what other spinoffs or off-spec Compute Node implementations could be created.

Our hardware specifications are open-source; you don’t need our permission to fork them into your own creative implementation. Additionally, we standardized on the SFF-TA-1002 4C+ connector, which is readily available from multiple vendors. Creating your own Compute Node isn’t a trivial task, but we’re certain a number of vendors or open-source enthusiasts can build something that plugs into an Enclosure’s Compute Node slot without fully adhering to the node’s specification.

We asked our specification developer, Jon Choi, about what he would build if he didn’t have to play by his rules. He took a break from spec work just long enough to share these three concepts. Most of them skip mandatory signals, some may ignore the mechanical envelope, and one of them doesn’t have a CPU at all. We’re sharing them purely as a thought experiment, and to invite you to check out our specifications and see what you can do with them.

Concept 1: CoM/SoM carrier node

Jon has floated this concept a few times to us. Compute-on-Module (CoM) and System-on-Module (SoM) boards like the Raspberry Pi Compute Modules or Radxa’s boards are industrial and maker staples because they achieve what we’re working towards: the ability to swap the compute while keeping the rest of the system. So it’s fitting that we start with this moduleception.

This spinoff would have the same shape and connectors as a Compute Node, but with a CoM/SoM socket where the CPU and RAM would normally go. Depending on the socket, this carrier node may be versatile enough to work with modules from different manufacturers, similar to how the Turing Pi works.

Enclosures would recognize it as any other node, but there may be cases where the module doesn’t support our minimum required connector signals. The PCIe 4.0 x1 lane may go unrouted, or maybe the CoM/SoM's Ethernet controller doesn’t support at least 2.5Gbps.

But again, just because we can’t certify it doesn’t mean you shouldn’t build it. Jon points out that such a node would make for an excellent platform-testing tool. You’d be able to benchmark different architectures inside the same, spec-compatible Enclosure without making or buying separate nodes for every chip you want to test.

Concept 2: SSD hub

Here’s another practical no-brainer concept. We expect most spec-compatible Compute Nodes to cap out at two M.2 NVMe sticks, which would leave room for the rest of the node’s components while having enough storage for most use cases. This concept flips the script. We strip out most of the compute to cram in as many storage drives as possible.

A NAS-oriented Arm SoC like Rockchip’s RK3588 could power the hub. That chip has enough lanes to drive either eight 2.5” SATA SSDs plus a pair of M.2 slots, or a dense layout comprising 20 SATA M.2 slots—10 on top and 10 more underneath.

While we’re sure many users would love to have a spec-compatible storage node, this node may also not meet all the minimum required signals for a Compute Node. We imagine the hub would use its Ethernet interface to expose the storage to the other nodes in the Enclosure.

Concept 3: Diagnostics node

Here’s where things get really interesting. This node would still mount neatly into a Compute Node slot and draw power through the connector, but it’s not your typical computer. It’s an Enclosure benchmarking tool.

We imagine a general purpose version of this diagnostics node would have exposed instrumentation, such as electrical and USB signal analyzers, plus CANbus and GPIO headers on its I/O shield. A more purpose-built version would use its connector to probe its host’s power delivery, signal integrity, and other behaviors. It could have a small display on its I/O shield to show test results.

Such a node would be incredibly useful for vendors, but its design is also the reason it wouldn’t pass our future compatibility tests.

Build with OpenSFF

We’re developing the Compute Node Specification to make it work the same way with all compatible Enclosures and MMs, even if their vendors never directly worked together to make cohesive systems. But we’re looking forward to seeing what enterprising inventors will do when they decide that our standard is just a starting point.

If you enjoyed reading this, we invite you to learn more about OpenSFF and our specifications, and we would be grateful if you spread the word about our standard. For technical clarifications, partnerships, and other inquiries, reach out to our development team at [email protected].