AMD's Ryzen 3000-supporting X570 chipset examined

[HEXUS]

Lots of PCIe for ultra-fast storage.

Read more.

[MRFS]

In the first image "AMD X570: THE MOST MODERN I/O" see where that diagram says:
x8 PCIe Gen4. Does that mean the X570 chipset will NOT support "4x4" AICs
like the ASRock Ultra Quad M.2 AIC? The latter AIC needs a single x16 slot
to "bifurcate" those lanes into 4 @ x4, hence the nomenclature "4x4".

[MRFS]

P.S. See AORUS AIC GEN4 SSD here:
https://hexus.net/tech/news/storage/131189-gigabyte-aorus-nvme-gen4-ssd-launched-copper-fin-heatsink/
https://hexus.net/media/uploaded/2019/5/925eda35-423d-4905-8c83-ce2cceeec234.jpg

[MRFS]

P.S. also here, with a few bullet points:
https://pbs.twimg.com/media/D7oQOePUwAAPowF.jpg

[chinf]

In the first image "AMD X570: THE MOST MODERN I/O" see where that diagram says:
x8 PCIe Gen4. Does that mean the X570 chipset will NOT support "4x4" AICs
like the ASRock Ultra Quad M.2 AIC? The latter AIC needs a single x16 slot
to "bifurcate" those lanes into 4 @ x4, hence the nomenclature "4x4".

Good question. From a slot signalling perspective, you'd need to have a full 16-lane slot. Despite the red "x16 PCIe Gen 4" block in the second slide, I haven't yet seen any motherboards with such a configuration (full x16 slot via X570 chipset) - and even if there were any, it'd be pointless from a performance standpoint due to having to funnel all that bandwidth over a x4 Gen 4 link to the SoC.

I think to max out M.2 provision on X570, one would first need to have an X570 board that offers 2x x16-physical slots wired to the CPU (not all do). These slots can be run as x8x8, and then a 2-way AIC to go into one of these alongside a GPU (assuming this is a desktop that needs a display card). Otherwise, there's the HEDT platforms.

[MRFS]

Thanks for your feedback, chinf.

On the upper left of that first graphic,
see "PCIe 4.0 x4". That equals x16 lanes.

Also, in the orange blocks further to the left,
see "16x Graphics" and "4x Chipset Downlink"
i.e. 20 total.

So, the x16 "Graphics" slot might be available
to support a bifurcated "4x4" AIC.

It doesn't say how fast the "Chipset Downlink" is,
but it would be reasonable for that Downlink
to run at PCIe 4.0 speed e.g. see "1x4 NVMe".

[msroadkill612]

I liked parts of it a lot, but ...

"Here's a Corsair MP600 2TB NVMe M.2 SSD equipped with the latest Phison PS5016-E16 controller. It's benchmarked on an Asus Crosshair VIII Hero motherboard based on the X570 chipset. The left-hand benchmarks are run with the chipset's NVMe drive configuration set to PCIe 4 x4, whilst the right-hand benchmarks take in traditional PCIe 3 x4"u dont clearly say which nvme port is used. The more savvvy could guess, but not know.

A comparison benchmark of the same drive on the chipset's nvme port would be enlightening.

[MRFS]

> A comparison benchmark of the same drive on the chipset's nvme port would be enlightening.

Indeed!

The thrust of much of our activism over the past decade
has been to stress the upstream potential of x16 slots,
as compared to the limit necessarily imposed by a "DMI" bottleneck
that supports only x4 PCIe lanes.

That observation was quickly confirmed when prosumers
tried to configure RAID arrays downstream of DMI links
using very fast M.2 NVMe SSDs e.g. Samsung 970 Pro models.

It was almost like the "100th Monkey" phenomenon:
when one vendor finally released a "4x4" AIC with x16 edge connector,
other vendors saw the light and jumped onboard.

Let's hope the "auto detection" features of newer motherboards
will become standard features for future builders who wish
to do fresh OS installs to these 4x4 AICs.

It's about time for the NVMe standard to embrace "native" support
for all modern RAID modes, as did eventually happen with
native SATA ports.

[MRFS]

If anyone is interested, several months ago ASRock's Tech Support
responded very quickly in answer to our question about their "4x4" support
on the X399 and X399m motherboards. Here is the documentation
they generously provided:
http://supremelaw.org/systems/asrock/X399/

[Millennium]

If anyone is interested, several months ago ASRock's Tech Support
responded very quickly in answer to our question about their "4x4" support
on the X399 and X399m motherboards. Here is the documentation
they generously provided:
http://supremelaw.org/systems/asrock/X399/

Stick around! I am curious as to your activism

[MRFS]

Gen3 / Gen4 / Gen5 PCI-Express permutations for x16 expansion slots


Gen3: 4 x 2 x 8,000 / 8.125 = 7,877
Gen3: 4 x 4 x 8,000 / 8.125 = 15,754
Gen3: 8 x 2 x 8,000 / 8.125 = 15,754
Gen3: 16 x 1 x 8,000 / 8.125 = 15,754

Gen4: 4 x 2 x 16,000 / 8.125 = 15,754
Gen4: 4 x 4 x 16,000 / 8.125 = 31,508
Gen4: 8 x 2 x 16,000 / 8.125 = 31,508
Gen4: 16 x 1 x 16,000 / 8.125 = 31,508

Gen5: 4 x 2 x 32,000 / 8.125 = 31,508
Gen5: 4 x 4 x 32,000 / 8.125 = 63,016
Gen5: 8 x 2 x 32,000 / 8.125 = 63,016
Gen5: 16 x 1 x 32,000 / 8.125 = 63,016

There is a different frame encoding proposed
for PCIe 5.0, but I haven't read any documentation
of that future standard. Perhaps someone else here
can share a few links to documents outlining
that future encoding method.

[MRFS]

I can think of at least two ways of encoding a frame
in a way that is more efficient than the current 128b/130b "jumbo frame".
An easy one is to drop the 8th bit from standard ASCII, which
remains a 7-bit code (last time I looked). A more difficult one
is to perform some form of compression on that 128b/130b "jumbo frame",
such that each frame ends up being variable in length.
I'm very curious to know the details about the proposed layout and
logic of the Gen5 PCIe frame.

The other "wild idea" I visualized recently is to map a 2-dimensional
motherboard plane onto the six sides of a cube: each "side"
would have its own set of PCIe expansion slots and DIMM slots.
The literal "core" of this cube would be a future CPU connected
to those slots via lanes that are designed to be as short as possible,
to defeat the attenuation that occurs with very high data rates
over very long transmission wires.

[DanceswithUnix]

An easy one is to drop the 8th bit from standard ASCII, which
remains a 7-bit code (last time I looked).

I think you scuppered your own idea there, ASCII never had an 8th bit so you can't drop it Possibly that's why at the basic level the PCIe bus doesn't use ASCII, it needs 32 bit transfers as a minimum to comply with the underlying PCI spec, if 7 bits would do then I'm sure the people writing the spec would have used it.

[MRFS]

We used to do systems programming on minicomputers:

we had to write a quick "reformat" task that would reset the 8th bit
if the ASCII source files had set the 8th bit. So, assuming the unused 8th bit
is reset (equal to zero), here's one very rough "compression" example:

01111111 01111111 01111111 (spaces shown only for clarity)
when the unused 8th bit is dropped, becomes
1111111 1111111 1111111

Likewise, if the 8th bit is set, then:

10000000 10000000 10000000
becomes
0000000 0000000 0000000

Of course, such a protocol would need to be arbitrated
successfully between the sender and receiver,
before standard ASCII could be transmitted in that manner.

In contrast, the binary strings above may NOT eliminate
that 8th bit, because "binary" means that each binary digit
is transmitted "as is".

Hope this helps.

/s/ Paul

[DanceswithUnix]

We used to do systems programming on minicomputers:

we had to write a quick "reformat" task that would reset the 8th bit

Am interested in your top bit clearing, were you transferring data from a Prime computer by any chance? Those are the only ones I have come across that set the top bit rather than clear it when handling ascii bytes.

Please believe me though, ASCII has no relevance at all to PCIe which almost entirely deals with binary graphics, network and filesystem data. Even modern characters are some mapping into the 32 bit Unicode space, usually using utf-8 which requires all 8 bits per byte.