I love the Zen architecture and think that the original Zeppelin and Raven Ridge are impressive pieces of silicon, but I have a problem with the consumer AMD ecosystem: I hate the Socket AM4 platform as a whole.
The story begins at ISSCC 2018, which is when AMD did this presentation detailing Zeppelin SoC features:
https://www.slideshare.net/AMD/isscc-2018-zeppelin-an-soc-for-multichip-architectures
...then, after seeing articles analysing the slides like this one:
https://fuse.wikichip.org/news/1064/isscc-2018-amds-zeppelin-multi-chip-routing-and-packaging/2/
...I began to believe how much Socket AM4 is limiting Zen based SoCs true potential, and how Ryzen Embedded V1000 (Raven Ridge) and EPYC Embedded 3000 (One or two Zeppelin dies, equivalent to AM4 8C Ryzen or TR3 16C ThreadRipper) are actually far superior since they expose many more features. Just check their Product Briefs:
https://www.amd.com/system/files/documents/3000-family-product-brief.pdf
https://www.amd.com/system/files/documents/v1000-family-product-brief.pdf
The problem is that Zeppelin and Raven Ridge are not merely a CPU or APU, they are actually full blown SoCs (This will stop being true in Zen 2 generation due to I/O and CPUs being separate dies, but the Processor package as a whole would still be a SoC). Zeppelin has an impressive range of integrated I/O functions, including the classic IMC, 32 PCIe Lanes that are actually multiprotocol, an USB Controller with four 3.0 Ports (Or more...), and miscellaneous stuff like Azalia/HD Audio, SPI, LPC, I2C and SMBus. Depending on the package and platform that Zeppelin is delivered in, several of those features are not used to their fullest extend, and this is the reason why I despise Socket AM4. Raven Ridge seems to have major differences (More on those later) and is perhaps even better suited for a consumer facing SoC than Zeppelin is.
The Integrated Memory Controller comes first. Zeppelin actually has two 64/72 Bits IMCs, which support the entire range of DDR4 DIMM standards: UDIMM, UDIMM w/ECC, RDIMM and RDIMM w/ECC. In Socket AM4, only UDIMM and (Somewhat oficially) UDIMM w/ECC are supported. EPYC Embedded, instead, supports them all. Interesingly, the Product Brief of EPYC Embedded mentions NVDIMM support, but this may not be a direct reference to Optane NVDIMMs in LGA 3647 Cascade Lake, which is the only one that I'm aware that can do that.
In the case of Raven Ridge, memory support is a bit... curious. In Socket AM4, standard Ryzen APUs does not support ECC whereas Ryzen Pro APUs do (Sure, go ahead and tell me where the hell can I buy one), but this has to be compared to Ryzen CPUs where even the non Pro ones supports ECC. Ryzen Embedded is even more curious, since while ECC is officially supported, AMD claims that it can use only 1 DPC (DIMM Per Channel) which means only two DDR4 Slots, whereas the standard AM4 Ryzen APUs that should be based on the same Raven Ridge die works fine with four slots/2 DPC. I think that this may be because AMD claims 3200 MHz DDR4 support on Ryzen Embedded which may not be possible with 2 DPC, but I don't know why they didn't tiered it like this:
https://www.pugetsystems.com/blog/2018/06/06/2nd-Gen-AMD-Ryzen-Supported-RAM-Speeds-1175/
I'm somewhat dissapointed about why Ryzen Embedded lacks 2 DPC support. Also, there is no mention about RDIMM.
Most of the fun in the Zen SoCs is in the multiprotocol controllers. Intel had been using these for a while in its Chipsets under the name of Flex IO, where several lanes can be configured to work with one of multiple protocols, usually either PCIe or USB, or PCIe, SATA and an 1G MAC. Here is an example:
https://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/5
Zeppelin has two 16 lane multiprotocol controllers which is where the maximum of 32 PCIe Lanes comes from, but as lanes can be configured in different ways and most times a minimum of other I/O is preferable, is almost impossible that you actually see a Zeppelin being used only for PCIe. Moreover, the controllers are not identical, they have slighty different capabilities. Reelevant to them, one controller with the full 16 lanes is lost in setups with 8 Zeppelins like those found in Dual EPYC 7000 platforms since it has to be configured for IF (Infinity Fabric). For up to 4 Zeppelin dies like a Single EPYC 7000, the multiprotocol controllers aren't touched since there are four dedicated IF controllers for die-to-die communications that covers up to 4 dies, which is why ThreadRipper with 2 Zeppelin and Single EPYC with 4 Zeppelin has a total of 64 and 128 lanes, respectively, whereas Dual EPYC remains at 128 but with each Processor providing 64.
The first 16 lane controller can be set up as either PCIe or IF (Infinity Fabric), but as the IF mode is only used in the mentioned Dual Socket 8 Zeppelin setups, for anything not Dual EPYC 7000 it is always treated as a pure PCIe Controller, and the main one at that. In PCIe mode, the PCIe lane granularity is amazing since it can scale down from one 16x port to sixteen 1x ports, with any middle ground configuration like 8x/8x, 8x/4x/4x, 8x/4x/1x/1x/1x/1x and such apparently supported (I think that there is a limit that caps out at a total of 8 PCIe Ports, not sure if per controller or between both controllers, but either way, sixteen 1x may not be possible). For comparison, Intel consumer platforms (LGA 1155/1150/1151) integrated PCIe Controller only supports 16x, 8x/8x and 8x/4x/4x modes (Also, bifurcation of the Processor PCIe Controller is ONLY supported if you paid for a high end Chipset. It falls under the "Processor feature controlled by the Chipset" category, which is a pure artificial limitation). This is important not necessarily due to the physical amount of PCIe Slots, but due to in-slot bifurcation for when a single PCIe Card has multiple individual PCIe Devices. Major examples are NVMe adapters like the AsRock ULTRA QUAD M.2 CARD, where the second M.2 slot would not be functional in an Intel consumer platform because it can't go below 8x/4x/4x, yet it should work fine with Zeppelin. If you can't bifurcate the way you need, you would have to get more expensive PCIe Cards that include a PCIe Switch like the PLX PEX series. I'm not sure if Socket AM4 has any limitation that doesn't allow this controller to bifurcate beyond 8x/8x, as I don't recall seeing 4x/4x/4x/4x to get cards like the mentioned one working in an AM4 Motherboard, but such capability is exposed in ThreadRipper.
The second multiprotocol controller is far more interesing as it supports more protocols. Besides IF and PCIe, as can be seen on Slide 13 of AMD original presentation, half of it supports SATA, configurable on a per lane basis, so possible configurations ranges from 16 PCIe Lanes and 0 SATA to 8 PCIe Lanes and 8 SATA. Additionally, it was revealed during the EPYC Embedded launch that this controller also supports pairing two lanes to provide a 10G MAC (It has to be coupled with either a 1G or 10G PHY to get full NIC functionality. This is similar to Intel Chipsets, they provide an integrated 1G MAC which has to be paired with a PHY like the Intel i219-V), and up to 4 of them are supported, thus using 8 lanes. However, due to the lack of technical information, I don't know if the 10G MAC shares the same lanes than SATA, so that you could get either 8 SATA or 4 10G MACs, or a combination like half and half, or if they are multiplexed into the other set of 8 lanes which means that you could do 0 PCIe Lanes, 4 10G MAC, and 8 SATA out of this controller. In Socket AM4, this controller isn't fully exposed, instead, only 8 lanes (Probably the SATA half) are available, and 4 of those always go connected to the Chipset. This is where Zen loses a lot of I/O potential.
Raven Ridge is actually quite different. In theory, the first controller is still 16 lanes, but it is configured as 8 PCIe and 8 IF (Unsupported arrangement in Zeppelin, since it is either all PCIe or all IF), with the IF half used to wire to the integrated GPU. These are the famous 8 lanes that you're missing, and the reason why Ryzen APUs can get only a 16x PCIe Slot working as 8x, or in 8x/8x Motherboards, the second slot doesn't work. The second controller is also a bit weird, as given Socket AM4 capabilities it should at least expose 8 lanes, yet Raven Ridge supposedly only supports 2 SATA. Due to lack of info, I'm not sure if the second controller is as capable as Zeppelin one, but in Ryzen Embedded, it is capable of providing two 10G MACs, albeit I don't know what are the possible arrangements.
Next comes the USB Controller. For some reason, compared to Intel Chipsets, USB in AMD SoCs is independent instead of being multiplexed into some of the PCIe lanes. Zeppelin has 4 USB 3.0 (5 Gb p/s) Ports, and this is perhaps its most blatant weakness as a consumer SoC since that is not enough for a full fledged desktop computer. One option was for Super I/O chips to provide a PS/2 Keyboard Port to maybe save an USB, but this is a backwards solution. In some EPYC Embedded Motherboards, like the Supermicro M11SDV-8C+-LN4F (You can check the Block Diagram in its Manual), there are onboard USB Hubs to fanout an USB 3 Port to multiple USB 2 Ports, but this arrangement is not ideal either. Wasting PCIe Lanes on separate USB Controllers is viable but at that point you may as well consider adding back the Promontory Chipset. Spending 2/4 PCIe Lanes on an Intel ThunderBolt 3 Controller with 1/2 Ports is also an option.
Raven Ridge has, again, interesing differences compared to Zeppelin. It has 4 USB 3.1 Ports capable of 10 Gb p/s instead of just 5 Gb p/s, and in addition to them, is has two more Ports, a single 5 Gb p/s, plus an USB 2.0 (Which should be XHCI based). With 6 Ports it gets a bit more viable to drive a desktop platform with no additional help.
Finally, you have miscellaneous I/O. Both Zeppelin and Raven Ridge have them in amounts that I didn't really paid attention to, but at the bare minimum, you have SPI/eSPI, which is used by the SPI Flash EEPROM with the Motherboard Firmware, Azalia (Also known as HD Audio), used by the HDA audio codec (The Realtek ALC series chips that you see integrated in every consumer Motherboard hold a monopoly over this Bus), and LPC, used by the Super I/O chip. Actually, whereas in all previous platforms the Chipset takes care of all this miscellaneous I/O, the Zen SoCs, even in Socket AM4 packaging, are wired to them directly:
https://www.kitguru.net/components/...r-direct-nvme-storage-promontory-pch-usb-3-1/
Zen has also built in I2C/SMBus, but I'm not sure about whenever they're either exposed or used in Socket AM4 platforms. Typically, SMBus is managed by the Super I/O chip, which is wired via SMBus to the DIMM Slots to read a DIMM SPD EEPROM, and it can also be optionally exposed in PCIe Slots if the Motherboard manufacturer decided to wire one or multiple slots with SMBus support (This is uncommon).
Even though as the embedded Zen SoCs versions shows us that the Zen SoCs could drive a platform entirely by themselves, AMD decided to stick with a Processor plus Chipset platform topology. Moreover, as AMD said that they were commiting to Socket AM4 for at least one more generation, this situation is not going to change for at least one or two more years, before AMD revisits if it wants a bigger Socket with more room for I/O pins or not. So, what the current Chipsets actually does for the Socket AM4 platform? Based on the fact that even miscellaneous I/O is handled by the Zen SoCs, and the few I/O that isn't is done by the Super I/O, the Zen Chipsets are downgraded to be merely just glorified PCIe Switches, SATA Controllers and USB Controllers. Actually, Promontory (Both 300 and 400 generations) completely sucks at being a PCIe Switch due to it exposing only PCIe 2.0 Lanes, and worse if you're of the PCI Passthrough crowd as these lanes offer no PCIe ACS support, being the cause why every AM4 Motherboard in Linux has all the Chipset devices grouped in a single IOMMU Group (Maybe the 500 series is competent enough in this regard). As everything that Promontory does can be done by the Zen SoCs better than it, the Zen Chipsets seems a bit redundant to me...
Now, the idea behind the Zen Chipsets is that they work as a form of I/O multiplexer so that the Processor package is not clogged with all the required pins that would be needed to provide all optional I/O itself (It could be that it was impossible to have more pins in Socket AM4 package, thus some I/O had to be sacrificed). In both Intel and AMD platforms, the Chipset takes 4 PCIe Lanes (Intel calls the Processor-to-Chipset Bus DMI 3, but it seems to be just a different protocol with physical PCIe properties), and provides a plethora of I/O pins, which are connected to physical Ports. Under normal circunstances, it is not expected for everything to be under heavy use all at once, so you shouldn't feel the massive bottleneck that the uplink between the Processor-to-Chipset really is (Well, except on Intel consumer platforms, where a single PCIe 3.0 NVMe SSD can saturate the Chipset uplink all by itself, yet Intel wants to drive two or more out of the Chipset. Socket AM4 actually has 4 lanes from the SoC used for this purpose). Point is, as the Zen SoCs already have enough I/O builtin to drive a consumer platform, unless you require more than what they provide (A problem with USB Ports only, as you have more of enough of everything else), you may not require a Chipset at all for multiplexing further I/O. Not only that, but by wiring everything directly to the SoC, you're enjoying both lower latency, as data would not have to travel though a middleman chip, dedicated bandwidth for all I/O, lower power usage as there is one less chip, and lower costs for that same reason, and no Motherboard real state for it.
Ironically, AMD missed a rather good chance to do a full demonstration of Zen SoC capabilities back at launch. I'm sure that someone should remember that AMD announced the A300/X300 Chipsets for mITX platforms, which were not going to provide any I/O as the Zen SoCs had enough to fill a mITX sized Motherboard, instead, they were to serve just as some form of platform security chips. At the end, these never appeared on the market, mITX Motherboards simply used the standard Chipset versions. In truth, these Chipsets were unnecessary to being with, albeit it seems that the Socket AM4 platform is what forces you to have a one, whereas in embedded form, Zen SoCs don't require it and can work standalone. Alas, you would have had to sacrifice socket upgradeability for an embedded Zen, but if you believe the way I do, that may not necessarily be a big deal for some kind of long term setups.
The chip which Zen can't replace is apparently the Super I/O. There are two functions that the Zen SoCs doesn't seems capable of doing: Being a PWM Fan Controller, and being an ACPI Embedded Controller. Amusingly, the previously mentioned Supermicro M11SDV-8C+-LN4F seems to not have a Super I/O at all, instead, it has an ASpeed AST2500 BMC, which is a dedicated Processor with a miniGPU intended for remote management, but apparently it can also supercede the functions of a standard Super I/O. Thus, with these two chips you're already providing the vast majority of features of a platform.
Also, for remote management, AMD supports DASH, which it claims that is similar to Intel vPro. DASH support is supposed to be embedded in the Zen SoC itself, but as a feature both it and its usage are pretty unknow and not very well covered. DASH requires Motherboard support, and very, very few do. Besides, given the fact that Server Motherboards commonly uses dedicated BMCs, it not sure what use cases vPro and DASH are supposed to be good for, but at least I'm aware that vPro works, and DASH... who knows.
So, after reading all this, you're wondering if using Zen as a SoC like I want is truly possible, or just a hypothetical scenario. If you were following the Embedded Ryzen and EPYC products, you should already know that products using them the way I'm proposing already exist: Supermicro has several Embedded EPYC 3000 based Motherboards, and there were also the UDOO BOLT and the Sapphire AMD FS-FP5V based on the Ryzen Embedded V1000. The problem with the existing products is that they're either too expensive due to being Server oriented, which is the case of Supermicro Motherboards, or too small with almost no expansion due to being HTPC oriented. I think that even if one was limited to the preexisting embedded Zen models, they could be an interesing niche in the consumer DIY Motherboard for people that know what they're getting.
For example, the Ryzen Embedded V1756B is quite similar to the Ryzen 2400G, and so is the EPYC Embedded 3251 when compared to the Ryzen 1700 (The 2700 is Zen+ based, thus not as close comparison). They also cost around the same from AMD in quantities of 1000. The worst con is that you're purchasing an inseparable Processor + Motherboard pair, which is not end user upgradeable as socketed systems are (Ironically, AMD long longevity Sockets hurts more how embedded versions could compare than say, Intel...). This may not even be an issue for people that don't upgrade the platform often, which should be most non-enthusiasts users. You're also having a non-standard heatsink mounting mechanism, since embedded Motherboards usually have a custom one due to the nonstandard height of the embedded packages, so forget about tower heatsinks and overclocking in general. The models have also lower TDP, but also lower clocks. In the pro section, you get all the features advantages of a pure Zen SoC, having no ZIF Socket or Chipset should also lower costs, and while in general there would be less I/O, the one that you get will perform equal or better.
Where does this leaves a supposed Ryzen Embedded V1756B and a coupled Motherboard at? As a more specialized 2200G/2400G + A320 based Motherboard replacement for the masses, that should be around the same price than them but with a much more interesing builtin feature set.
The story begins at ISSCC 2018, which is when AMD did this presentation detailing Zeppelin SoC features:
https://www.slideshare.net/AMD/isscc-2018-zeppelin-an-soc-for-multichip-architectures
...then, after seeing articles analysing the slides like this one:
https://fuse.wikichip.org/news/1064/isscc-2018-amds-zeppelin-multi-chip-routing-and-packaging/2/
...I began to believe how much Socket AM4 is limiting Zen based SoCs true potential, and how Ryzen Embedded V1000 (Raven Ridge) and EPYC Embedded 3000 (One or two Zeppelin dies, equivalent to AM4 8C Ryzen or TR3 16C ThreadRipper) are actually far superior since they expose many more features. Just check their Product Briefs:
https://www.amd.com/system/files/documents/3000-family-product-brief.pdf
https://www.amd.com/system/files/documents/v1000-family-product-brief.pdf
The problem is that Zeppelin and Raven Ridge are not merely a CPU or APU, they are actually full blown SoCs (This will stop being true in Zen 2 generation due to I/O and CPUs being separate dies, but the Processor package as a whole would still be a SoC). Zeppelin has an impressive range of integrated I/O functions, including the classic IMC, 32 PCIe Lanes that are actually multiprotocol, an USB Controller with four 3.0 Ports (Or more...), and miscellaneous stuff like Azalia/HD Audio, SPI, LPC, I2C and SMBus. Depending on the package and platform that Zeppelin is delivered in, several of those features are not used to their fullest extend, and this is the reason why I despise Socket AM4. Raven Ridge seems to have major differences (More on those later) and is perhaps even better suited for a consumer facing SoC than Zeppelin is.
The Integrated Memory Controller comes first. Zeppelin actually has two 64/72 Bits IMCs, which support the entire range of DDR4 DIMM standards: UDIMM, UDIMM w/ECC, RDIMM and RDIMM w/ECC. In Socket AM4, only UDIMM and (Somewhat oficially) UDIMM w/ECC are supported. EPYC Embedded, instead, supports them all. Interesingly, the Product Brief of EPYC Embedded mentions NVDIMM support, but this may not be a direct reference to Optane NVDIMMs in LGA 3647 Cascade Lake, which is the only one that I'm aware that can do that.
In the case of Raven Ridge, memory support is a bit... curious. In Socket AM4, standard Ryzen APUs does not support ECC whereas Ryzen Pro APUs do (Sure, go ahead and tell me where the hell can I buy one), but this has to be compared to Ryzen CPUs where even the non Pro ones supports ECC. Ryzen Embedded is even more curious, since while ECC is officially supported, AMD claims that it can use only 1 DPC (DIMM Per Channel) which means only two DDR4 Slots, whereas the standard AM4 Ryzen APUs that should be based on the same Raven Ridge die works fine with four slots/2 DPC. I think that this may be because AMD claims 3200 MHz DDR4 support on Ryzen Embedded which may not be possible with 2 DPC, but I don't know why they didn't tiered it like this:
https://www.pugetsystems.com/blog/2018/06/06/2nd-Gen-AMD-Ryzen-Supported-RAM-Speeds-1175/
I'm somewhat dissapointed about why Ryzen Embedded lacks 2 DPC support. Also, there is no mention about RDIMM.
Most of the fun in the Zen SoCs is in the multiprotocol controllers. Intel had been using these for a while in its Chipsets under the name of Flex IO, where several lanes can be configured to work with one of multiple protocols, usually either PCIe or USB, or PCIe, SATA and an 1G MAC. Here is an example:
https://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/5
Zeppelin has two 16 lane multiprotocol controllers which is where the maximum of 32 PCIe Lanes comes from, but as lanes can be configured in different ways and most times a minimum of other I/O is preferable, is almost impossible that you actually see a Zeppelin being used only for PCIe. Moreover, the controllers are not identical, they have slighty different capabilities. Reelevant to them, one controller with the full 16 lanes is lost in setups with 8 Zeppelins like those found in Dual EPYC 7000 platforms since it has to be configured for IF (Infinity Fabric). For up to 4 Zeppelin dies like a Single EPYC 7000, the multiprotocol controllers aren't touched since there are four dedicated IF controllers for die-to-die communications that covers up to 4 dies, which is why ThreadRipper with 2 Zeppelin and Single EPYC with 4 Zeppelin has a total of 64 and 128 lanes, respectively, whereas Dual EPYC remains at 128 but with each Processor providing 64.
The first 16 lane controller can be set up as either PCIe or IF (Infinity Fabric), but as the IF mode is only used in the mentioned Dual Socket 8 Zeppelin setups, for anything not Dual EPYC 7000 it is always treated as a pure PCIe Controller, and the main one at that. In PCIe mode, the PCIe lane granularity is amazing since it can scale down from one 16x port to sixteen 1x ports, with any middle ground configuration like 8x/8x, 8x/4x/4x, 8x/4x/1x/1x/1x/1x and such apparently supported (I think that there is a limit that caps out at a total of 8 PCIe Ports, not sure if per controller or between both controllers, but either way, sixteen 1x may not be possible). For comparison, Intel consumer platforms (LGA 1155/1150/1151) integrated PCIe Controller only supports 16x, 8x/8x and 8x/4x/4x modes (Also, bifurcation of the Processor PCIe Controller is ONLY supported if you paid for a high end Chipset. It falls under the "Processor feature controlled by the Chipset" category, which is a pure artificial limitation). This is important not necessarily due to the physical amount of PCIe Slots, but due to in-slot bifurcation for when a single PCIe Card has multiple individual PCIe Devices. Major examples are NVMe adapters like the AsRock ULTRA QUAD M.2 CARD, where the second M.2 slot would not be functional in an Intel consumer platform because it can't go below 8x/4x/4x, yet it should work fine with Zeppelin. If you can't bifurcate the way you need, you would have to get more expensive PCIe Cards that include a PCIe Switch like the PLX PEX series. I'm not sure if Socket AM4 has any limitation that doesn't allow this controller to bifurcate beyond 8x/8x, as I don't recall seeing 4x/4x/4x/4x to get cards like the mentioned one working in an AM4 Motherboard, but such capability is exposed in ThreadRipper.
The second multiprotocol controller is far more interesing as it supports more protocols. Besides IF and PCIe, as can be seen on Slide 13 of AMD original presentation, half of it supports SATA, configurable on a per lane basis, so possible configurations ranges from 16 PCIe Lanes and 0 SATA to 8 PCIe Lanes and 8 SATA. Additionally, it was revealed during the EPYC Embedded launch that this controller also supports pairing two lanes to provide a 10G MAC (It has to be coupled with either a 1G or 10G PHY to get full NIC functionality. This is similar to Intel Chipsets, they provide an integrated 1G MAC which has to be paired with a PHY like the Intel i219-V), and up to 4 of them are supported, thus using 8 lanes. However, due to the lack of technical information, I don't know if the 10G MAC shares the same lanes than SATA, so that you could get either 8 SATA or 4 10G MACs, or a combination like half and half, or if they are multiplexed into the other set of 8 lanes which means that you could do 0 PCIe Lanes, 4 10G MAC, and 8 SATA out of this controller. In Socket AM4, this controller isn't fully exposed, instead, only 8 lanes (Probably the SATA half) are available, and 4 of those always go connected to the Chipset. This is where Zen loses a lot of I/O potential.
Raven Ridge is actually quite different. In theory, the first controller is still 16 lanes, but it is configured as 8 PCIe and 8 IF (Unsupported arrangement in Zeppelin, since it is either all PCIe or all IF), with the IF half used to wire to the integrated GPU. These are the famous 8 lanes that you're missing, and the reason why Ryzen APUs can get only a 16x PCIe Slot working as 8x, or in 8x/8x Motherboards, the second slot doesn't work. The second controller is also a bit weird, as given Socket AM4 capabilities it should at least expose 8 lanes, yet Raven Ridge supposedly only supports 2 SATA. Due to lack of info, I'm not sure if the second controller is as capable as Zeppelin one, but in Ryzen Embedded, it is capable of providing two 10G MACs, albeit I don't know what are the possible arrangements.
Next comes the USB Controller. For some reason, compared to Intel Chipsets, USB in AMD SoCs is independent instead of being multiplexed into some of the PCIe lanes. Zeppelin has 4 USB 3.0 (5 Gb p/s) Ports, and this is perhaps its most blatant weakness as a consumer SoC since that is not enough for a full fledged desktop computer. One option was for Super I/O chips to provide a PS/2 Keyboard Port to maybe save an USB, but this is a backwards solution. In some EPYC Embedded Motherboards, like the Supermicro M11SDV-8C+-LN4F (You can check the Block Diagram in its Manual), there are onboard USB Hubs to fanout an USB 3 Port to multiple USB 2 Ports, but this arrangement is not ideal either. Wasting PCIe Lanes on separate USB Controllers is viable but at that point you may as well consider adding back the Promontory Chipset. Spending 2/4 PCIe Lanes on an Intel ThunderBolt 3 Controller with 1/2 Ports is also an option.
Raven Ridge has, again, interesing differences compared to Zeppelin. It has 4 USB 3.1 Ports capable of 10 Gb p/s instead of just 5 Gb p/s, and in addition to them, is has two more Ports, a single 5 Gb p/s, plus an USB 2.0 (Which should be XHCI based). With 6 Ports it gets a bit more viable to drive a desktop platform with no additional help.
Finally, you have miscellaneous I/O. Both Zeppelin and Raven Ridge have them in amounts that I didn't really paid attention to, but at the bare minimum, you have SPI/eSPI, which is used by the SPI Flash EEPROM with the Motherboard Firmware, Azalia (Also known as HD Audio), used by the HDA audio codec (The Realtek ALC series chips that you see integrated in every consumer Motherboard hold a monopoly over this Bus), and LPC, used by the Super I/O chip. Actually, whereas in all previous platforms the Chipset takes care of all this miscellaneous I/O, the Zen SoCs, even in Socket AM4 packaging, are wired to them directly:
https://www.kitguru.net/components/...r-direct-nvme-storage-promontory-pch-usb-3-1/
Zen has also built in I2C/SMBus, but I'm not sure about whenever they're either exposed or used in Socket AM4 platforms. Typically, SMBus is managed by the Super I/O chip, which is wired via SMBus to the DIMM Slots to read a DIMM SPD EEPROM, and it can also be optionally exposed in PCIe Slots if the Motherboard manufacturer decided to wire one or multiple slots with SMBus support (This is uncommon).
Even though as the embedded Zen SoCs versions shows us that the Zen SoCs could drive a platform entirely by themselves, AMD decided to stick with a Processor plus Chipset platform topology. Moreover, as AMD said that they were commiting to Socket AM4 for at least one more generation, this situation is not going to change for at least one or two more years, before AMD revisits if it wants a bigger Socket with more room for I/O pins or not. So, what the current Chipsets actually does for the Socket AM4 platform? Based on the fact that even miscellaneous I/O is handled by the Zen SoCs, and the few I/O that isn't is done by the Super I/O, the Zen Chipsets are downgraded to be merely just glorified PCIe Switches, SATA Controllers and USB Controllers. Actually, Promontory (Both 300 and 400 generations) completely sucks at being a PCIe Switch due to it exposing only PCIe 2.0 Lanes, and worse if you're of the PCI Passthrough crowd as these lanes offer no PCIe ACS support, being the cause why every AM4 Motherboard in Linux has all the Chipset devices grouped in a single IOMMU Group (Maybe the 500 series is competent enough in this regard). As everything that Promontory does can be done by the Zen SoCs better than it, the Zen Chipsets seems a bit redundant to me...
Now, the idea behind the Zen Chipsets is that they work as a form of I/O multiplexer so that the Processor package is not clogged with all the required pins that would be needed to provide all optional I/O itself (It could be that it was impossible to have more pins in Socket AM4 package, thus some I/O had to be sacrificed). In both Intel and AMD platforms, the Chipset takes 4 PCIe Lanes (Intel calls the Processor-to-Chipset Bus DMI 3, but it seems to be just a different protocol with physical PCIe properties), and provides a plethora of I/O pins, which are connected to physical Ports. Under normal circunstances, it is not expected for everything to be under heavy use all at once, so you shouldn't feel the massive bottleneck that the uplink between the Processor-to-Chipset really is (Well, except on Intel consumer platforms, where a single PCIe 3.0 NVMe SSD can saturate the Chipset uplink all by itself, yet Intel wants to drive two or more out of the Chipset. Socket AM4 actually has 4 lanes from the SoC used for this purpose). Point is, as the Zen SoCs already have enough I/O builtin to drive a consumer platform, unless you require more than what they provide (A problem with USB Ports only, as you have more of enough of everything else), you may not require a Chipset at all for multiplexing further I/O. Not only that, but by wiring everything directly to the SoC, you're enjoying both lower latency, as data would not have to travel though a middleman chip, dedicated bandwidth for all I/O, lower power usage as there is one less chip, and lower costs for that same reason, and no Motherboard real state for it.
Ironically, AMD missed a rather good chance to do a full demonstration of Zen SoC capabilities back at launch. I'm sure that someone should remember that AMD announced the A300/X300 Chipsets for mITX platforms, which were not going to provide any I/O as the Zen SoCs had enough to fill a mITX sized Motherboard, instead, they were to serve just as some form of platform security chips. At the end, these never appeared on the market, mITX Motherboards simply used the standard Chipset versions. In truth, these Chipsets were unnecessary to being with, albeit it seems that the Socket AM4 platform is what forces you to have a one, whereas in embedded form, Zen SoCs don't require it and can work standalone. Alas, you would have had to sacrifice socket upgradeability for an embedded Zen, but if you believe the way I do, that may not necessarily be a big deal for some kind of long term setups.
The chip which Zen can't replace is apparently the Super I/O. There are two functions that the Zen SoCs doesn't seems capable of doing: Being a PWM Fan Controller, and being an ACPI Embedded Controller. Amusingly, the previously mentioned Supermicro M11SDV-8C+-LN4F seems to not have a Super I/O at all, instead, it has an ASpeed AST2500 BMC, which is a dedicated Processor with a miniGPU intended for remote management, but apparently it can also supercede the functions of a standard Super I/O. Thus, with these two chips you're already providing the vast majority of features of a platform.
Also, for remote management, AMD supports DASH, which it claims that is similar to Intel vPro. DASH support is supposed to be embedded in the Zen SoC itself, but as a feature both it and its usage are pretty unknow and not very well covered. DASH requires Motherboard support, and very, very few do. Besides, given the fact that Server Motherboards commonly uses dedicated BMCs, it not sure what use cases vPro and DASH are supposed to be good for, but at least I'm aware that vPro works, and DASH... who knows.
So, after reading all this, you're wondering if using Zen as a SoC like I want is truly possible, or just a hypothetical scenario. If you were following the Embedded Ryzen and EPYC products, you should already know that products using them the way I'm proposing already exist: Supermicro has several Embedded EPYC 3000 based Motherboards, and there were also the UDOO BOLT and the Sapphire AMD FS-FP5V based on the Ryzen Embedded V1000. The problem with the existing products is that they're either too expensive due to being Server oriented, which is the case of Supermicro Motherboards, or too small with almost no expansion due to being HTPC oriented. I think that even if one was limited to the preexisting embedded Zen models, they could be an interesing niche in the consumer DIY Motherboard for people that know what they're getting.
For example, the Ryzen Embedded V1756B is quite similar to the Ryzen 2400G, and so is the EPYC Embedded 3251 when compared to the Ryzen 1700 (The 2700 is Zen+ based, thus not as close comparison). They also cost around the same from AMD in quantities of 1000. The worst con is that you're purchasing an inseparable Processor + Motherboard pair, which is not end user upgradeable as socketed systems are (Ironically, AMD long longevity Sockets hurts more how embedded versions could compare than say, Intel...). This may not even be an issue for people that don't upgrade the platform often, which should be most non-enthusiasts users. You're also having a non-standard heatsink mounting mechanism, since embedded Motherboards usually have a custom one due to the nonstandard height of the embedded packages, so forget about tower heatsinks and overclocking in general. The models have also lower TDP, but also lower clocks. In the pro section, you get all the features advantages of a pure Zen SoC, having no ZIF Socket or Chipset should also lower costs, and while in general there would be less I/O, the one that you get will perform equal or better.
Where does this leaves a supposed Ryzen Embedded V1756B and a coupled Motherboard at? As a more specialized 2200G/2400G + A320 based Motherboard replacement for the masses, that should be around the same price than them but with a much more interesing builtin feature set.
Last edited:
Facebook
Twitter