Were I to guess, I think it might be either an initial lack of low end part for POWER10 (Sforza being this for POWER9), or the mandatory use of OMI, that Raptor is disappointed about.
EDIT: While the above may be a concern, there is credible (in my opinion) suspicion that Raptor may in fact be concerned about part of the firmware stack being closed-source, or in some other way not owner-controllable. If you only wish to read the original post about OMI, please skip to the “Options for implementing OMI” heading.
Talospace and Phoronix suspect that IBM may be requiring some firmware blobs (at least initially) to remain closed-source:
Phoronix
Libre/Open-Source POWER10 Hardware Systems Unlikely Until At Least 2022
While Raptor Computing Systems has been making fabulous 100% open-source/libre hardware systems based around POWER9 with the likes of their Talos II and Blackbird systems, don’t hold your breath on quickly seeing fully-open POWER10 systems…
This does seem to better explain the rather harsh comments that Raptor made about IBM “blocking” their products, and that “POWER10 systems from competitors in the interim will not meet the normal Raptor standards due to the causative IBM decisions”.
If we want to be optimistic about the way Raptor talks about the “interim”, I have some speculation: For POWER9, IBM presents itself as having entirely separate firmware for its PowerVM systems (IBM i, AIX, Linux on PowerVM). Maybe IBM is holding back the OpenPOWER firmware until 2022, because the only machines shipping in 2021 will be those running PowerVM.
The following is the rest of the post as originally written:
Options for implementing OMI
To detail the OMI issue, as I see it, POWER10 board vendors have three options:
OMI Option A - OMI modules
This is akin to how all IBM POWER8, and some IBM POWER9 machines attached memory; IBM would manufacture custom “CDIMMs”, modules with memory chips and Centaur memory-controller/buffer/L4-cache. An article by Johan de Gelas (Anandtech) has photos and diagrams of this.
With POWER10 and OMI, this is less of a proprietary solution, and I believe Micron has said they will make these modules. Using OMI memory modules directly would make the switchover from DDR4 to DDR5 very simple, just buy newer OMI modules; however, unless other widely used architectures (ARM, x86) also adopt this, these modules might not see similar economies of scale, or even if the POWER10 market can drive the necessary volume, resellers of OMI memory may be hard to come by, and less willing to deal with individual end-users.
OMI Option B - on-board controller, DDR4/DDR5 modules
As I mentioned in the Hot Chips 32 post, if you look at Raptor’s proposal for the POWER8 Talos I, they planned to use normal DDR3 DIMMs by moving the required Centaur chips onto their mainboard, which I imagine adds expense, complexity, and consumes board space. Looking at the Talos I design, these were probably under the two rectangular heatsinks between the DIMM slots:
Talos I diagram legend
|
|
|
|
| A. |
1 × PCI slot |
G. |
8 × DDR3 ECC DIMM slots |
| B. |
GPIO header |
H. |
6 × PCI Express slots |
| C. |
mPCIe slot |
I. |
AST2400 BMC with HDMI video |
| D. |
8 × 6 Gbps internal SATA |
J. |
Integrated I/O |
| E. |
2-port USB 3.0 header |
K. |
1 × socketed POWER8 SCM |
| F. |
2 × internal USB 3.0 |
|
|
OMI Option C - OMI riser cards, DDR4/DDR5 modules
A more flexible but more expensive alternative could be to have riser cards which themselves use standard DDR4/DDR5 memory. This could let you switch out the riser interface when DDR5 becomes available rather than switching out the entire mainboard.
I am taking inspiration from what the Russian company Yadro did for its Vesnin POWER8 machine (@olddellian mentioned these earlier in this thread).
Conclusion
My guess is that Raptor will take the option B approach, and may be waiting until 2022 for DDR5 to reach mainstream (more or less), rather than release a board that will only work with DDR4. On the off chance that OMI really appears to be taking off in 2021, they could change plans and switch to option A and release an OMI-module board instead.
