Are you at liberty to say anything more specific about issues with Steamroller or Excavator? This is the first I've heard about problems like this.
A short story long:
http://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf
That's the BKDG for Steamroller.
The memory controller
Take a look at 2.9.8.3
Before Steamroller the memory controller used in AMD CPU/APUs were designed in house. They remained almost unchanged between the introduction (K8) and the decommissioning (Trinity / Richland). In Steamroller AMD used an outsourced hybrid DDR3 / GDDR5 memory controller. This memory controller requires a significant amount of additional code to work and has two separate firmwares too. Unlike the older memory controllers designed by AMD, this controller is configured by writing an array to the SRAM of the memory controller.
Reading or writing the SRAM region of the controller requires specific conditions (the controller must be first turned on and then again stalled). This makes it extremely painful to configure, if you wish to use a non-standard (AGESA) configuration. There are also some specific conditions for the controller which cannot be violated, such as it's frequency (depends on Phy ratio on REFCLK). Not to mention that you need to access and configure many direct, indirect and memory mapped configuration spaces before you can even read the current settings.
The slight issue on Steamroller is that the SRAM interface used to configure the controller doesn't work... :sneaky: Both read and write operations to the SRAM will result either completely gibberish data or cause the system to crash. The issue it causes it that there is no way to calibrate the memory properly or even use any other settings than the ones which are hard coded to the PMU (memory controller) firmware. There is no way to calibrate the receivers or change the address/command timings, delays, drive strengths or ODT values. All of these are configured through the PMU SRAM and when the interface doesn't work... You probably get the idea.
As a side note, I achieved close to DDR-2800 memory frequency on Trinity by simply calibrating the previously mentioned settings correctly. They can make a huge difference in the maximum memory frequency. Knowing how bandwidth starved these APUs are, even an additional 50MHz in memory frequency would be a massive win.
In Excavator designs, which have the same DDR3 controller side as Steamroller but the secondary PHY is DDR4 instead of GDDR5 the SRAM issue is fixed and everything works like it is supposed to. That would be great news for AM4 Bristol Ridge parts, however due integration of the memory controller it cannot be configured for anything higher than 2400MHz still... In order to hit higher memory speeds on Bristol Ridge you need to increase BCLK once again
The power management
In Trinity AMD introduced a new "Serial VID Interface" standard, SVI2. Otherwise SVI2 is the same as the older SVI, however it introduced a command interface and features such as load-line control, offset control and telemetry feedback. The telemetry feedback function sent information about the measured voltages and current back to the APU. Since the telemetry data was based on actual measurements, it was pretty accurate (± 5%) and could be used for power management. In Trinity and Richland APUs SVI2 worked great and was used as it is supposed to. On average the accuracy of the telemetry measurements were ±2% or less.
Then Steamroller was introduced. Like all AMD CPU/APUs before it, Steamroller relied on fused values in estimating it's power consumption. This isn't exactly accurate method especially on mobile products, since they have extremely wide operating temperature range (5 - 100°C on Steamroller mobile parts). The power consumption can vary heavily depending on the temperature alone. So did AMD try to optimize the performance of their Steamroller APUs by making the power management much more accurate by utilizing the recently introduced SVI2 standard (which was supported on all Steamroller compliant designs anyway)?
Nope, they certainly didn't. In fact on Steamroller their completely disabled the telemetry and left all the reference values unprogrammed. As a result, Steamroller based results cannot improve their performance in optimal (cool) conditions or when undervolted. Since the power management only relies on factory programmed (fused) parameters in it's estimations, the actual operating conditions don't make any different to it's behavior D:
Also because they have no way to measure the actual power consumption, the CPU cores will be throttled down when the iGPU utilization exceeds certain threshold. Otherwise they have no way to guarantee that the power consumption stays within the specs. This feature is called as GeAPM.
You can try this by enabling a negative
offset voltage for the VDDCR and / or the VDDNB from the bios and then check the what does the APU estimate as it's power consumption... The result will be exactly the same, regadless if the actual voltage is 1.0000V or 1.5000V
Carrizo is the first AMD design ever (besides the GPUs) which can adjust it's performance based on the actual operating conditions, and that's the single biggest reason why it is as power efficient as it is. However because AMD didn't bother to revise / update the SVI2 standard for Carrizo compability (Excavators need three main voltage planes, SVI2 has two), all Excavator designs must now use two separate SVI2 controllers in a piggy back configuration. Three high current VRM planes is bad enough in terms of cost and two controller on top of that is certainly not helping.
Facebook
Twitter