GIGABYTE AM4 Motherboards: PCIe 4.0 Ready for Ryzen 3000
by Gavin Bonshor on May 21, 2019 11:00 AM EST
In preparation for the launch of AMD's next generation of Ryzen processors, GIGABYTE has released a wave of firmware updates for its X470 and B450 AM4 socket motherboards. The new firmware adds listed support for AMD's Ryzen 3000 series (Matisse) processors prior to launch.
GIGABYTE has launched its own firmware updates offering users support AMD's upcoming Ryzen 3000 series processors. This not only means users can use their existing AM4 motherboards with the upcoming CPUs when they launch later this year, but upon some investigation with a GIGABYTE X470 Gaming 7 Wi-Fi motherboard we had in the lab, I flashed it to the latest F40 firmware update, and found that PCIe 4.0 could be set within the PCIe slot configurator.
GIGABYTE X470 Gaming 7 Wi-Fi running the latest F40 firmware confirms some PCIe 4.0 support
While there is no official confirmation from GIGABYTE itself (or from any of the other vendors for that fact), PCIe 4.0 support on current generation AM4 motherboards will be done on a model by model basis. Back at CES 2019, we confirmed that AMD's 3000 series CPUs would become the world's first mainstream CPU to support PCIe 4.0 x16. However, PCIe 4.0 support on current motherboards in the market will depend on how they are built: PCIe 4.0 specifications state that traces should be under a minimum length, and any longer requires a PCIe 4.0 redriver to boost the signal further down the board. Due to this, it is probable, but not confirmed that some existing X370, B350, X470 and B450 models may not offer the full capacity of PCIe 4.0 that Ryzen 3000 is expected to see when it is launched in the coming months.
As there is a lot of speculation around AMD's Ryzen 3000 series, X570, and which current generation AM4 motherboards will support the new PCIe 4.0 interface, it's clear that it will feature in some capacity. In what capacity exactly is currently unknown. Given the limitations, PCIe 4.0 might be limited to the top slot on most motherboards. Without existing redrivers on the lower located slots of ATX sized AM4 models, it wouldn't actually be possible to benefit from PCIe 4.0 with the distance restriction in play for an effective signal. This would mean that the top slot could operate at PCIe 4.0, whereas each of the other slots below would be locked down to PCIe 3.0 by default. Obviously new X570 boards will be built with this in mind.
The wave of F40 firmware updates can be downloaded from the relative product pages of each of the current GIGABYTE B450 and X470 models. GIGABYTE has also made us aware that we can expect similar firmware updates for its B350 and X370 models at the end of the month.
Related Reading
- The GIGABYTE X470 Gaming 7 Wi-Fi Motherboard Review: The AM4 Aorus Flagship
- AMD Ryzen 3rd Gen 'Matisse' Coming Mid 2019: Eight Core Zen 2 with PCIe 4.0 on Desktop
- AMD Reiterates 7nm Roadmap: Navi, Matisse, & Rome to Launch in Q3
- AMD to Host "Next Horizon Gaming" Event & Product Unveil at E3 2019: June 10th, 3pm PT
- Analyzing B450 for AMD Ryzen: A Quick Look at 25+ Motherboards
Source: GIGABYTE
Facebook
Twitter
RSS
32 Comments
View All Comments
willis936 - Tuesday, May 21, 2019 - link
PCIe 4.0 specifications state that traces should be under a minimum lengthShouldn't this say "under a maximum length"?
Alexvrb - Tuesday, May 21, 2019 - link
They were talking about the new PCIe Airwave standard. They refer to the channels as "air traces". Anyway, you can't have the radios too close or it jacks the signal up!peevee - Tuesday, May 21, 2019 - link
There is no AM4 specification anywhere.There is way more (+400 or so) pins compared to the previous slot.
I wonder why. Could it include support for 256 lines of data bus to memory, instead of 128 currently used by all CPUs in the class?
Smell This - Tuesday, May 21, 2019 - link
Funny you brought this up ...I'm wondering if the expansion/doubling of DDR4/DDR5 bank groups effectively means the same, and 'next-gen' memory controllers are in the cue ...
brakdoo - Tuesday, May 21, 2019 - link
Memory banks are internal. They have nothing to do with IO lanes.BTW AM3 didn't support Video Output (for Raven Ridge)./ USB 3 / Audio(I2S interface) directly from CPU so don't expect too much.
AM4 ends 2020 or 21 (probably 21) because of DDR5 but CPUs might be backwards compatible like AM2 to AM3 and the change from DDR2 to DDR3.
shing3232 - Tuesday, May 21, 2019 - link
Just like AM2+ and AM3 :ppeevee - Tuesday, May 21, 2019 - link
"Video Output (for Raven Ridge)./ USB 3 / Audio(I2S interface) directly from CPU"These are tiny.
My point is it is 8 cores in a mainstream CPU instead of 1, but memory bus is still 128 bits like it was 15 years ago or so. And like it is on phones now. And the only tasks where CPU performance matter today are on big data sets which do not fit in caches. Having 4 independent 64-bit channels, or maybe even 8 32-bit, would be nice.
peevee - Tuesday, May 21, 2019 - link
But not like in Threadripper configuration with memory controllers on different chips with added latencies etc, using a huge 4000-pin slots supporting 8 channels but using only half of them.Alexvrb - Tuesday, May 21, 2019 - link
This wouldn't be an issue in a chiplet configuration. The I/O is in the, wait for it, I/O die. The real issues have already been addressed by Valantar. Mainly being that outside of edge cases (better suited to a HEDT platform), the only common case that needs it is a fairly large iGPU. But even then, it wouldn't be enough. The first XB1 doubled the width of their DDR3 bus and if it wasn't for the SRAM (in the hands of a good dev anyway) it would have had total garbage useable bandwidth.If you really need massive memory bandwidth for an iGPU, instead of doubling the DDR bus width, add a secondary GDDR or HBM interface for the iGPU. Pin for pin GDDR and especially HBM beat the absolute snot out of DDR. The latency is higher but again for iGPUs it wouldn't matter. Put a socket/slot on the board for HBM or GDDR, like an oldschool optional cache. You wouldn't even need to include it on every board.
peevee - Wednesday, May 22, 2019 - link
Why do you need 16 cores with 32 threads when you have only 128 bits of memory to feed them? WHAT are you going to process over and over and over which all fits into cache? Video does not. RAW pics from 42+ Mpix cameras do not. Large codebases which builds can be paralleled to 32 threads do not, neither sources nor binaries.Peak performance numbers mean nothing if you as a user do not benefit. If it takes 10ms after your click on 4 cores it does not matter if it takes 3ms on 16 cores. If it takes 10 minutes on 4 cores, it does not fit into cache and is not going to take 3 minutes on 16 cores limited by the memory bus.