• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

New Zen microarchitecture details

Page 35 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

The Stilt

Golden Member
Dec 5, 2015
1,709
3,057
106
AMD is executing very well when it comes to products.
I feel completely the opposite. For example the APUs released after Trinity are something I previously would never have thought someone would actually release to the market.

With Steamroller a huge amount of features which are either not fully working or completely broken / missing, stuff that doesn't work as documented, etc. It's like someone pulled the plug on the project and many parts of the design were left incomplete, broken or untested. The situation improved quite alot in Carrizo / Bristol Ridge, but even they still contain some silly errors.

IIRC Trinity was the last project which had John Bruno as the chief engineer. It might be a coincidence, but Trinity is IMO the very last AMD design which is fully functional.
 
Last edited:

itsmydamnation

Platinum Member
Feb 6, 2011
2,217
1,822
136
I feel completely the opposite. For example the APUs released after Trinity are something I previously would never have thought someone would actually release to the market.

With Steamroller a huge amount of features which are either not fully working or completely broken / missing, stuff that doesn't work as documented, etc. It's like someone pulled the plug on the project and many parts of the design were left incomplete, broken or untested. The situation improved quite alot in Carrizo / Bristol Ridge, but even they still contain some silly errors.

IIRC Trinity was the last project which had John Bruno as the chief engineer. It might be a coincidence, but Trinity was IMO the very last AMD design which is fully functional.

I think its likely just a cost vs reward thing, is it worth the cost in fixing it vs the reward it will bring. They already know margins on the APU's will be continually squeezed until Zen arrives.

The better question is how many engineers worked on SR/EX and their SOC's vs trinity, with the companies future entirely ridding on Zen, i bet thats where the lion share of resources went.
 

The Stilt

Golden Member
Dec 5, 2015
1,709
3,057
106
I think its likely just a cost vs reward thing, is it worth the cost in fixing it vs the reward it will bring. They already know margins on the APU's will be continually squeezed until Zen arrives.

The better question is how many engineers worked on SR/EX and their SOC's vs trinity, with the companies future entirely ridding on Zen, i bet thats where the lion share of resources went.
Personally I find it pretty essential to have a functional (non bogus) power management on a design which is intended for mobile products. Also I find a fully functional / properly implemented memory controller pretty essential on a design whose graphics performance fully depends on the memory bandwidth it provides...

Most likely the memory controlers on Steamroller and Excavator based designs themselves are fine, since they are a licensed IP afterall. Most likely the existing issues are caused by the piss poor implementation. On Carrizo there are fewer issues with the memory controller, as it can at least train the memory and program the parameters correctly D:

I would be happy to hear that people who worked on Hounds, Stars, Bulldozer, Piledriver and Cat cores also worked on Zen. It's the people who worked on Steamroller and Excavator who should be keelhauled, flogged and then banned working on semiconductors for life.
 

el etro

Golden Member
Jul 21, 2013
1,581
14
81
Personally I don't believe that AMD has sent Zen silicon to anywhere yet. The motherboard manufacturers do need AM4 APUs / CPUs in order to make their AM4 boards, but Bristol Ridge (Carrizo) chips can be used for that purpose.

The clocks on the alleged Zen "A0" part don't tell much really, even if they were true. Nowdays the manufacturers only make new, major die revisions if they absolutely have to (in order to fix errata, which cannot be fixed thru µcode). Things were different back in the day, when both AMD and Intel released steppings to improve the characteristics of the design (power consumption and scaling).

Usually the prototype chips have higher than usual safety margins (for obvious reasons), so the initial silicon revisions can clock just as high as the final ones.

Recently AMD has done very few major die revisions between the initial tape out and the release:

Orochi:

OR-A0 = 3.6GHz (initial)
OR-B0 = 4.1GHz
OR-B2F = 4.3GHz (release, +19.4%)

Trinity:

TN-A0 = 4.1GHz (initial)
TN-A1 = 4.2GHz (release)

Carrizo:

CZ-A0 = 3.4GHz (initial)
CZ-A1 = 3.4GHz (release)

Generation 1 Bulldozer was an exception, since it required four major steppings and several minor revisions before it was ready for release (still had major errata in it).

For example, Stoney Ridge launched with it's initial die revision (A0).
Thevenin said exactly that if the clockspeeds are high enough, Zen will be very good.
 
May 11, 2008
18,309
829
126
I feel completely the opposite. For example the APUs released after Trinity are something I previously would never have thought someone would actually release to the market.

With Steamroller a huge amount of features which are either not fully working or completely broken / missing, stuff that doesn't work as documented, etc. It's like someone pulled the plug on the project and many parts of the design were left incomplete, broken or untested. The situation improved quite alot in Carrizo / Bristol Ridge, but even they still contain some silly errors.

IIRC Trinity was the last project which had John Bruno as the chief engineer. It might be a coincidence, but Trinity is IMO the very last AMD design which is fully functional.
Well, i have an apu (A10-6700) and with high settings all games that are a few years old are playable( I am okay with a 1280*1024 setting if it can handle it with my older games). That is not bad at all for an APU.
The only limit for an APU is the memory technology. The lower in latency and higher the bandwidth the memory technology gets, the more an APU benefits. So, AMD was ahead of time in x86 space. I think when it comes to errata, nobody has a clean record. It is such an incredibly complicated feature to develop a high performance processor and it depends on so much different variables.

Intel is doing as good as they do because the communication between their fab and development teams is i think perfect. It is one company. With AMD, it is the same issue as with every company were the sections split up and function as separate entities that work together. Miscommunications, delays, more administration, higher costs and reduction of overall efficiency.
 
Last edited:

Abwx

Diamond Member
Apr 2, 2011
9,146
990
126
A single pin with 0.3mm diameter (0.07mm² CSA) can carry around 1.49A of current.

AMD themselves rate the pins used on AM3/+ and FM2/+ packages for 1.50A in temperatures at or below 30°C. Meanwhile a single pin with 0.25mm diameter (0.049mm² CSA) can carry around 1.15A.

Despite I don't expect first generation Zen CPUs to have basically any margin left for overclocking, I certainly hope AMD hasn't made too grave compromises when designing the socket infrastructure.
2.42mW/cm, and a much better electrical and thermal conductions than LGA for instance, so if there s concerns that s surely not in their implementation..
 

del42sa

Member
May 28, 2013
26
11
81
Personally I find it pretty essential to have a functional (non bogus) power management on a design which is intended for mobile products. Also I find a fully functional / properly implemented memory controller pretty essential on a design whose graphics performance fully depends on the memory bandwidth it provides...

Most likely the memory controlers on Steamroller and Excavator based designs themselves are fine, since they are a licensed IP afterall. Most likely the existing issues are caused by the piss poor implementation. On Carrizo there are fewer issues with the memory controller, as it can at least train the memory and program the parameters correctly D:

I would be happy to hear that people who worked on Hounds, Stars, Bulldozer, Piledriver and Cat cores also worked on Zen. It's the people who worked on Steamroller and Excavator who should be keelhauled, flogged and then banned working on semiconductors for life.
Very true...., the same Thevenin said on SA forum. Kaveri was quite disappointment with broken power management and I do agree, Trinity APU was well made.

http://semiaccurate.com/forums/showpost.php?p=228720&postcount=31

https://www.semiaccurate.com/forums/showpost.php?p=238085&postcount=5

http://semiaccurate.com/forums/showpost.php?p=235472&postcount=328
 
Last edited:

Exophase

Diamond Member
Apr 19, 2012
4,439
8
81
I feel completely the opposite. For example the APUs released after Trinity are something I previously would never have thought someone would actually release to the market.

With Steamroller a huge amount of features which are either not fully working or completely broken / missing, stuff that doesn't work as documented, etc. It's like someone pulled the plug on the project and many parts of the design were left incomplete, broken or untested. The situation improved quite alot in Carrizo / Bristol Ridge, but even they still contain some silly errors.

IIRC Trinity was the last project which had John Bruno as the chief engineer. It might be a coincidence, but Trinity is IMO the very last AMD design which is fully functional.
Personally I find it pretty essential to have a functional (non bogus) power management on a design which is intended for mobile products. Also I find a fully functional / properly implemented memory controller pretty essential on a design whose graphics performance fully depends on the memory bandwidth it provides...

Most likely the memory controlers on Steamroller and Excavator based designs themselves are fine, since they are a licensed IP afterall. Most likely the existing issues are caused by the piss poor implementation. On Carrizo there are fewer issues with the memory controller, as it can at least train the memory and program the parameters correctly D:

I would be happy to hear that people who worked on Hounds, Stars, Bulldozer, Piledriver and Cat cores also worked on Zen. It's the people who worked on Steamroller and Excavator who should be keelhauled, flogged and then banned working on semiconductors for life.
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.
 

deasd

Senior member
Dec 31, 2013
201
15
51
Orochi:

OR-A0 = 3.6GHz (initial)
OR-B0 = 4.1GHz
OR-B2F = 4.3GHz (release, +19.4%)

Trinity:

TN-A0 = 4.1GHz (initial)
TN-A1 = 4.2GHz (release)

Carrizo:

CZ-A0 = 3.4GHz (initial)
CZ-A1 = 3.4GHz (release)

Generation 1 Bulldozer was an exception, since it required four major steppings and several minor revisions before it was ready for release (still had major errata in it).

For example, Stoney Ridge launched with it's initial die revision (A0).
Bulldozer was an exception is mainly because it's based on brand new 32nm SOI when in 2011...... like Zen which is on 14nm Finfet this year. Requiring heavily errata is pretty regular when alter to new process.
 

The Stilt

Golden Member
Dec 5, 2015
1,709
3,057
106
Bulldozer was an exception is mainly because it's based on brand new 32nm SOI when in 2011...... like Zen which is on 14nm Finfet this year. Requiring heavily errata is pretty regular when alter to new process.
Llano came before Bulldozer (32nm SHP SOI).
 

The Stilt

Golden Member
Dec 5, 2015
1,709
3,057
106
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 :rolleyes:

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 :rolleyes:

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.
 
Last edited:

rvborgh

Member
Apr 16, 2014
190
80
101
Just for giggles, i thought i'd run a simulated Phenom X8 for you... (i normally run 16 of the cores at 3.5 GHz on my 48 core 61xx ES opteron system), ran 8 threads in CB 11.5, and set thread affinity to the fast cores.

Score was 8.09

https://www.youtube.com/watch?v=THhZTmkrxzQ&feature=youtu.be

here is the same run at 3.3 GHz

https://www.youtube.com/watch?v=ppvOUAVrHfQ&nohtml5=False

hope you enjoy.

PS: running 16 threads on all fast 3.5 GHz cores... i ended up with a score of 15.7

Hell, I'd be fine with a six or eight core Phenom II, so long as AMD fixes the bloody draw call deficit with their chipsets.

Sandybridge performance (absolute worst case scenario, mind) + eight cores (16 threads?) + lower power + fixed draw call deficit...Yep, I'd buy that.
 
Last edited:

MajinCry

Platinum Member
Jul 28, 2015
2,488
557
136
Just for giggles, i thought i'd run a simulated Phenom X8 for you... (i normally run 16 of the cores at 3.5 GHz on my 48 core 61xx ES opteron system), ran 8 threads in CB 11.5, and set thread affinity to the fast cores.

Score was 8.09

https://www.youtube.com/watch?v=THhZTmkrxzQ&feature=youtu.be

here is the same run at 3.3 GHz

https://www.youtube.com/watch?v=ppvOUAVrHfQ&nohtml5=False

hope you enjoy.

PS: running 16 threads on all fast 3.5 GHz cores... i ended up with a score of 15.7
The psuedo Phenom II x8 is better than the i7 3770k in Cinebench? And that Cinebench thing is just a marketing tool as well. Oh my. That thing could do World Machine 2 like a champ.

AMD better not cock up this time around. Gettin' all humpy for Zen.
 

Dresdenboy

Golden Member
Jul 28, 2003
1,730
554
136
citavia.blog.de
I'm afraid your data is incorrect.

http://www.pcper.com/reviews/Processors/AMD-A10-7800-and-A6-7400K-Review-AMD-Rounds-Out-Kaveri-Line/Results-Cinebench-R15

in CBR15, A6-7400K which is 1M2C, has only 70% additional performance(87 vs 149) when multithreaded. Not to mentioned 7400k has higher turbo of up to 3.9Ghz in single thread when there's almost none in MT. I think it just has roughly 60-65% yield which means almost 35% penalty.
Sorry for picking this up late, but I still had that tab open. ;)
Did you see the different scores at different TDP settings? I think, the consensus so far was, that while discussing CMT or SMT scaling, we left out power constraints and turbo modes. Constant clock frequency tests were ideal. With the P3DNow! data I get 73% (CB15) and 79% (CB11.5).
 

Azuma Hazuki

Golden Member
Jun 18, 2012
1,532
866
131
Awesome, The Stilt! This explains so, so much about things I'd been noticing as an integrator and end-user of AMD APU silicon.

Really really hoping they went all-in for Zen and have everything fixed up. I hope it gives Intel the swift kick in the shorts they've needed for a solid half decade.
 

Exophase

Diamond Member
Apr 19, 2012
4,439
8
81
A short story long:

http://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf

That's the BKDG for Steamroller.
Thanks for all the information, that was very in depth and informative.

I'm totally floored that the product ended up this way. It's pretty crazy that a company that has a long history doing DDR3 and GDDR5 memory controllers had to license from a third party a controller that can handle both. AMD's resources must have been incredibly strained.

I'm surprised to even hear a memory controller has firmware, let alone multiple firmwares. Configuration registers, sure, but firmware? So there is some microcontroller attached to the memory controller? I guess it could be there just for the initialization/calibration processes and not for actively servicing memory activity. But the FOSS purists must not be very happy about more binary blobs.

Do you know if Godaveri fixed any of these problems, or was that only a firmware update?

I assume SVI2 was used in a closed loop to control the VRM, then on Steamroller the VRM was just set to some fixed open loop value - am I understanding this correctly? I'm surprised to hear Carrizo was the first to regulate performance based on measured operating parameters like current and temperature, I thought AMD had been advertising this for a long time. Excavator was the first to have the dynamic clock compensation to minimize the amount of Vdroop gap needed, right? And do you know if/when Cat cores got these performance management features? I assume that was a big reason for Puma's improved efficiency, but that'd mean Carrizo wasn't the first.
 

The Stilt

Golden Member
Dec 5, 2015
1,709
3,057
106
Thanks for all the information, that was very in depth and informative.

I'm totally floored that the product ended up this way. It's pretty crazy that a company that has a long history doing DDR3 and GDDR5 memory controllers had to license from a third party a controller that can handle both. AMD's resources must have been incredibly strained.

I'm surprised to even hear a memory controller has firmware, let alone multiple firmwares. Configuration registers, sure, but firmware? So there is some microcontroller attached to the memory controller? I guess it could be there just for the initialization/calibration processes and not for actively servicing memory activity. But the FOSS purists must not be very happy about more binary blobs.

Do you know if Godaveri fixed any of these problems, or was that only a firmware update?

I assume SVI2 was used in a closed loop to control the VRM, then on Steamroller the VRM was just set to some fixed open loop value - am I understanding this correctly? I'm surprised to hear Carrizo was the first to regulate performance based on measured operating parameters like current and temperature, I thought AMD had been advertising this for a long time. Excavator was the first to have the dynamic clock compensation to minimize the amount of Vdroop gap needed, right? And do you know if/when Cat cores got these performance management features? I assume that was a big reason for Puma's improved efficiency, but that'd mean Carrizo wasn't the first.
I think the issues with the memory controller are mostly caused by the fact that it is a GDDR5 hybrid controller. In order to support GDDR5 (which never became available) AMD had basically to duplicate all the memory configuration related registers to allow proper configuration for both memory types. GDDR5 requires compeltely different PHY programming due being QDR instead of DDR, but also the fact that on DDR3 each channel is 64-bits wide and on GDDR5 they are 32-bits wide made the things way way more complex. Basically in DDR3 mode AMD had to split each 64-bit channel into two 32-bit channels in their integration. As result Steamroller has additional hardware (four identical macros) located between the CNB and the GNB... :sneaky:

I doubt a from the scratch design w/ proper integration wouldn't have illustrated any of these issues. They tried to pair their existing K8 ERA (mostly unchanged) infrastructure with a modern outsourced controller and this is how it came out.

What comes to the additional processors... Steamroller has separate CPUs for SMU (RISC), SAMU, and for PMU (memory controller).

Godavari is exactly the same part as Kaveri, just with slightly different factory configuration and more recent production. They share both the same microcode and the errata ;)

SVI2 was intended for closed loop function. On Steamroller it neither operated in open nor closed loop as all of the new features (over SVI) were completely disabled / ignored. On Steamroller designs SVI2 is nothing but a dumb interface which follows the VID commands from the APU, exactly the same as the ancient SVI.

AVFS exist in Carrizo and all discrete GPU ASICs after Hawaii. The only issue is that despite the hardware is there, AVFS is disabled on Tonga, Fiji ASICs... Even on Carrizo I have never seen it active (I can monitor that), but I must admit I have not looked much into it.

Mullins (aka. Carrizo-L) has some of the same features as Carrizo, such as cTDP and STAPM, however the power management is still MUCH more advanced in Carrizo. Puma is much more efficient core by the design, so even if the exactly same power management was introduced for it I doubt the efficiency would improve as much as on Carrizo.
 
May 11, 2008
18,309
829
126
I think the issues with the memory controller are mostly caused by the fact that it is a GDDR5 hybrid controller. In order to support GDDR5 (which never became available) AMD had basically to duplicate all the memory configuration related registers to allow proper configuration for both memory types. GDDR5 requires compeltely different PHY programming due being QDR instead of DDR, but also the fact that on DDR3 each channel is 64-bits wide and on GDDR5 they are 32-bits wide made the things way way more complex. Basically in DDR3 mode AMD had to split each 64-bit channel into two 32-bit channels in their integration. As result Steamroller has additional hardware (four identical macros) located between the CNB and the GNB... :sneaky:

I doubt a from the scratch design w/ proper integration wouldn't have illustrated any of these issues. They tried to pair their existing K8 ERA (mostly unchanged) infrastructure with a modern outsourced controller and this is how it came out.

What comes to the additional processors... Steamroller has separate CPUs for SMU (RISC), SAMU, and for PMU (memory controller).

Godavari is exactly the same part as Kaveri, just with slightly different factory configuration and more recent production. They share both the same microcode and the errata ;)

SVI2 was intended for closed loop function. On Steamroller it neither operated in open nor closed loop as all of the new features (over SVI) were completely disabled / ignored. On Steamroller designs SVI2 is nothing but a dumb interface which follows the VID commands from the APU, exactly the same as the ancient SVI.

AVFS exist in Carrizo and all discrete GPU ASICs after Hawaii. The only issue is that despite the hardware is there, AVFS is disabled on Tonga, Fiji ASICs... Even on Carrizo I have never seen it active (I can monitor that), but I must admit I have not looked much into it.

Mullins (aka. Carrizo-L) has some of the same features as Carrizo, such as cTDP and STAPM, however the power management is still MUCH more advanced in Carrizo. Puma is much more efficient core by the design, so even if the exactly same power management was introduced for it I doubt the efficiency would improve as much as on Carrizo.
That is an interesting read. Thanks. :thumbsup:
 

yuri69

Member
Jul 16, 2013
127
149
116
Kaveri seems to be a really sad chip. It was delayed. It didn't reach targeted GFOPS. It carries a never used GDDR5 memctrlr. It features bugged firmware in various IPs (instant frequency reductions). Oh, man.

It's always seemed like it had been rushed out and all budgets got cut.

Back in 2012 AMD chose Zen as their future core IP. Steering their budgets to Zen-related projects instead of crappy 15h ones would make sense.

You can find info about development of the Carrizo project being transfered from Sunnyvale, CA to India back in 2012. Giving priority to Zen dev this way. I guess something similar could have happen to Kaveri too.
 

monstercameron

Diamond Member
Feb 12, 2013
3,818
1
0
Kaveri seems to be a really sad chip. It was delayed. It didn't reach targeted GFOPS. It carries a never used GDDR5 memctrlr. It features bugged firmware in various IPs (instant frequency reductions). Oh, man.

It's always seemed like it had been rushed out and all budgets got cut.

Back in 2012 AMD chose Zen as their future core IP. Steering their budgets to Zen-related projects instead of crappy 15h ones would make sense.

You can find info about development of the Carrizo project being transfered from Sunnyvale, CA to India back in 2012. Giving priority to Zen dev this way. I guess something similar could have happen to Kaveri too.
Kaveri was a pretty good chip, don't understand how you came to this conclusion that it is "sad".
 

ASK THE COMMUNITY