Won’t the timing of each chipset on each board need to be painstakingly individually configured to avoid latency from a “default” profile used in all chips (which inherently vary between every batch)?
No, because PCIe works completely differently from RAM. PCIe is a packet-based protocol that's very latency-tolerant. (Multi-lane PCIe links may require deskew but that's a standard feature that has existed all along.) I think it was Marcan who tunneled PCIe over RS-232 and the chips didn't even notice.
This isn't really true for PCIe 4 and beyond. For example, if you use a competently manufactured PCIe 3 riser in a PCIe 4 GPU configuration then VGA will fail to POST more times than it succeeds (on the order of successfully booting 1/10), if it POSTs at all. Given how expensive PCIe 4 risers are most people choose to downgrade to PCIe 3 in the firmware settings.
The DRAM controller has been on the CPU socket since AMD's Opteron/Athlon 64 (2003) and Intel's Nehalem first-gen Core i5/i7 products (2008). AMD's recent migration toward multiple chiplets on the CPU package has not changed the direct connection between DRAM and the CPU socket.
>AMD's recent migration toward multiple chiplets on the CPU package has not changed the direct connection between DRAM and the CPU socket
This is true. However with the MCH off-chip and worst case inter core latency comparable a DRAM refresh cycle, AMD could in theory move the MCH away from the socket and see no major performance penalty.
Not to mention the Zen 2 IO die is just a cut-down version of X570, or maybe it is the other way around heh?
No, because PCIe works completely differently from RAM. PCIe is a packet-based protocol that's very latency-tolerant. (Multi-lane PCIe links may require deskew but that's a standard feature that has existed all along.) I think it was Marcan who tunneled PCIe over RS-232 and the chips didn't even notice.