tag:blogger.com,1999:blog-36524285316318278832024-03-18T10:47:45.959+01:00The New Citavia BlogSpeculation about future CPUs and GPUs based on patents, patches, leaks.Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-3652428531631827883.post-59771693022717432272016-11-12T13:13:00.000+01:002016-11-14T01:24:25.683+01:00Leaked Zen/Naples benchmarks appeared in SiSoftware's database [screenshots updated]After weeks without new Zen benchmark leaks showing up (Blenchmark doesn't seem to be one), there are some first in the SiSoftware database, dated 10/26. Have a look <a href="http://ranker.sisoftware.net/show_system.php?q=cea598ab99ae97af9eb8dfe2cffed8aa97a781e8d5e0c6ae93a680f8c5f4d2b7d2efdff98ab786b0&l=en" target="_blank">here</a>.<br />
<br />
Update: After some of the pages were removed at SiSoftware, I removed the links, so that the full resolution screenshots are available again.<br />
<br />
Before doing some analysis, there are the raw results:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiapaBGkiqmPXoHig3jN1zj0imivLugCML6MBF4PjFp0OG-5IT8tiRv-ptAUXL7znQ2FMhLPaH8Zrvf-gFvaz-qQNMgRj-xUB4YavcpmtbGN8DxTx0r6ZNF5eAD6bQFNO74mL4ae7tZDAc/s1600/Sandra_Diesel_Results_Overview.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="220" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiapaBGkiqmPXoHig3jN1zj0imivLugCML6MBF4PjFp0OG-5IT8tiRv-ptAUXL7znQ2FMhLPaH8Zrvf-gFvaz-qQNMgRj-xUB4YavcpmtbGN8DxTx0r6ZNF5eAD6bQFNO74mL4ae7tZDAc/s640/Sandra_Diesel_Results_Overview.png" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4YOR65I3ITRwsZuc8YqMsReHTmTLZXjr0KaSJbvcfULIV_ORvdzLAXggFcBJ070el5ecjoFe4pnX4CRvkrURCQT-4E-fPI5PoNOW3yIM0i0zukA-w4sHziVfu8EmwG57Xjq3n6yTg268/s1600/Sandra_FA_Result.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="504" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4YOR65I3ITRwsZuc8YqMsReHTmTLZXjr0KaSJbvcfULIV_ORvdzLAXggFcBJ070el5ecjoFe4pnX4CRvkrURCQT-4E-fPI5PoNOW3yIM0i0zukA-w4sHziVfu8EmwG57Xjq3n6yTg268/s640/Sandra_FA_Result.png" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCK4G_5mE7JzqL9dIWxPRFNxDJ4sPs6vzKyJkHwnunLhjtMxfdaEC50TFt170eHq0BN13mtlDp6fPF2DyXYZq3iFFdOZhQosNY8C8cTz2LiFojVQyMBASEGOxtoPUv7yJ-mZAmbOKgF5E/s1600/Sandra_MM_Results.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="198" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCK4G_5mE7JzqL9dIWxPRFNxDJ4sPs6vzKyJkHwnunLhjtMxfdaEC50TFt170eHq0BN13mtlDp6fPF2DyXYZq3iFFdOZhQosNY8C8cTz2LiFojVQyMBASEGOxtoPUv7yJ-mZAmbOKgF5E/s640/Sandra_MM_Results.png" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYmIguyKsJBT7c64-sy4wLV7tOttu-5cWgUh5n90knqSv-eqnPoBsgtQ6zyC6jYGudJH4GOVcN_XRudI1zTx2GFe4D2Vy1b-9i6fjQdFp6bk_wlzqqVOtdVBNXCNtl_73axpMKWI8n5E0/s1600/Sandra_Crypto_Results.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="162" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYmIguyKsJBT7c64-sy4wLV7tOttu-5cWgUh5n90knqSv-eqnPoBsgtQ6zyC6jYGudJH4GOVcN_XRudI1zTx2GFe4D2Vy1b-9i6fjQdFp6bk_wlzqqVOtdVBNXCNtl_73axpMKWI8n5E0/s640/Sandra_Crypto_Results.png" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://ranker.sisoftware.net/show_run.php?q=c2ffcdffd9b8d9e4dce8dbeadee6c0b28fbf99fc99a494b2c1fccdfb&l=en" target="_blank"><img border="0" height="148" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhw4reZWVpsrVIK-PMlsnnxMAB2nP5OICyNXLwK8f7BHG8WRhRN4Io2bgc-WYO5Fh7FwyBILUdW0Ytb9fM0LtjpXSRKwQMz4ojSiD5tNi-GaYlkefF7S4irDfd5rp4HfKTNx_BEvNcYURU/s640/Sandra_PCI_Results.png" width="640" /></a></div>
<br />
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com25tag:blogger.com,1999:blog-3652428531631827883.post-52770732710648341442016-10-28T00:25:00.002+02:002016-10-28T00:25:49.311+02:00Stoney Ridge 6W Engineering Sample spottedThe well known Zauba shipment database <a href="https://www.zauba.com/import-64-bit-stoney-hs-code.html" target="_blank">contains an entry</a> for a low power Stoney Ridge E2 engineering sample. As the OPN <span style="font-family: "courier new" , "courier" , monospace;">2E<b>16</b>01AOY<b>2</b>3E2</span> tells us, it runs at 1.6GHz base clock and has 2 cores (as expected for Stoney Ridge). The first "E" letter denotes an embedded part, confirmed by the <a href="http://www.cpu-world.com/info/id/AMD-ES-identification.html" target="_blank">ES OPN decoding sheet</a> at CPU-World.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWYKqR2-w7U0QG-lXmJV5h6C8k3-eQYqQllNRffo47HmekQYjvxC-U6cBGQXjnItVeyrRcaSmi8isS3naivA0_dfJ8OlGYHSSzcId7AYFNtzn8E0eRnnysh4de6PkVboNHxTsYvjqmeGk/s1600/SR_ES_6W.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="171" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWYKqR2-w7U0QG-lXmJV5h6C8k3-eQYqQllNRffo47HmekQYjvxC-U6cBGQXjnItVeyrRcaSmi8isS3naivA0_dfJ8OlGYHSSzcId7AYFNtzn8E0eRnnysh4de6PkVboNHxTsYvjqmeGk/s640/SR_ES_6W.png" width="640" /></a></div>
<br />
Interestingly, the ES entry also lists the TDP, which is a low 6W for this dual core, which is one of the last descendants of the Bulldozer or Construction Core line. Next to it, there is a 15W model, which is already available as E2-9010 APU.<br />
<br />
For comparison, the highest clocked AMD dual core APU with a similar TDP has a base clock of 1.2 GHz (<a href="http://www.cpu-world.com/CPUs/Puma/AMD-G-Series%20GX-212JC.html" target="_blank">GX-212JC</a>). An upcoming model, likely of the same Puma core powered "Steppe Eagle" family, will be running at 1.6 GHz while coming with a TDP of 10 W (<a href="http://www.cpu-world.com/CPUs/Puma/AMD-G-Series%20GX-216HC.html" target="_blank">GX-216HC</a>).<br />
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com6tag:blogger.com,1999:blog-3652428531631827883.post-73545108508845710102016-08-22T03:42:00.002+02:002016-08-22T19:05:24.266+02:00Two days to go until AMD's Hot Chips presentation - how about Zen's core size?<span style="font-family: inherit;"><i>TL;DR: Zen's many integer schedulers might be related to dedicated dependency chain handling. And the Zen core might be just 4.9 mm² incl. L2 cache.</i></span><br />
<br />
Here are some last speculative thoughts before we'll hear about Zen at Hot Chips 28, from the guy, who told you first about Bulldozer's and Zen's microarchitectures, AMD's upcoming 32 core server chip, and some other interesting things. Now I can say this, as AMD did present a first view on Zen's microarchitecture just a day after my last blog posting. Again, I was pretty close. This simply depends on the amount of data found in patches and patents.<br />
<br />
However, some things are different: The speculated Zen microarchitecture <a href="http://dresdenboy.blogspot.com/2016/02/new-amd-zen-core-details-emerged.html" target="_blank">shown here on this blog</a> had a unified scheduler for the 4 ALUs and a second one for the AGUs, while Zen actually has 6 separate schedulers instead. The base for my assumption was the cat core heritage. But of course, a unified scheduler for 4 execution units holding lots of µOps is still a big step up from a scheduler, which only has to issue to two units (cat cores). Now what's the reason for this configuration? At first, there are many possible typical design trade-off related reasons, like area, delays, buffer sizes, power efficiency. But there are also some interesting concepts, like a dependency chain oriented handling of instruction streams. If some code has an instruction level parallelism greater than one, there are groups of instructions, which at some point could be executed independently of the main flow, until their result gets fed back. These groups and sections of the main flow could also be called dependency chains, where it is not possible to execute a newer instruction before an older one, as each of them in the chain depends on some result of its predecessing operation. Here is an example:<br />
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;">mov eax, [edi]<br />add eax, ecx<br />imul edi, eax<br />cmp [ebp+08h], edi<br />jnz out</span></blockquote>
This code actually can't be executed out-of-order. All the logic put into an out-of-order scheduler would be a waste of energy in this case. And multiple same type execution units for parallel issue wouldn't help to speed this up either. A single scheduler with an integer execution unit (IEU), and an address generation unit (AGU) would be enough. The latter wouldn't even need a separate scheduler, similar to the K7, K8, K10 series of CPUs. This could be one reason for Zen's individual schedulers, as one identified dependency chain could be sent to a single integer scheduler and one AGU scheduler if there are memory operands. The other schedulers might even be clock gated then.<br />
<br />
<a href="http://www.freepatentsonline.com/8769539.html" target="_blank">U.S. Patent No. 8769539</a> covers a scheduler, which can be switched between out-of-order and in-order operation. One of the inventors is Zen project leader Suzanne Plummer, while Dan Hopper is also an important member of the Zen x86 core design team. In combination with many other patents (for example <a href="http://www.freepatentsonline.com/y2012/0023314.html" target="_blank">US20120023314</a>), which cover dependency chain related logic, there might be such a scheduler in Zen.<br />
<br />
Knowing the dependency chain also offers several efficiency measures. One patent covered different latencies for "far source operands" and close ones, i.e. coming from a different "lane" or the same. Bypass networks could be implemented in a somewhat more relaxed way, which improves delay and power efficiency.<br />
<h3>
A Zen core size estimation</h3>
After talking about Zen's die size just days ago, there is another size, which likely will be revealed at Hot Chips: the size of a Zen core. Earlier this year I created a table to estimate that size based on Excavator module components and some scaling factors. Based on AMD's statement about a <a href="http://www.anandtech.com/show/10578/amd-zen-microarchitecture-dual-schedulers-micro-op-cache-memory-hierarchy-revealed/3" target="_blank">density optimized process</a>, one of the unknowns in this calculation just became a bit smaller. Their statement could both mean dense metal layers or high density standard cell libs. For simplicity and lack of further data, assuming no density related scaling should do. Process related scaling is a different story, though.<br />
<br />
Using die photos, it is possible to measure the size of a graphics CU. On a <a href="https://www.flickr.com/photos/130561288@N04/sets/72157650403404920/with/28203687684/" target="_blank">Polaris 10 die</a>, the size of a graphics CU is about 2.96 mm², while <a href="http://arstechnica.com/gadgets/2015/02/amds-carrizo-system-on-chip-more-transistors-more-performance-less-power/" target="_blank">Carrizo</a> has 7.21 mm² CUs. This results in a scaling factor of about 41%. Putting this all together with some individual scaling factors based on design changes (e.g. more ALUs, smaller multiplier arrays, 64KB L1 I$ - already included in the "area 1C" number), results in a Zen core size incl. L2 cache of about 4.9 mm².<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDEnLcZ7G1gRin5oenNHtDTqsBAi5mKuk_kBH9FLtWz4SbmR6qCSR4yGvY5ypmetOC6-Wn6ihjuzR-ypo6C2sFDq_qAdfWWD-ZqbXp4PLrBREQXD0aD6syh4EndwlO-tV_rY_se5ccl3k/s1600/Zen_core_size.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDEnLcZ7G1gRin5oenNHtDTqsBAi5mKuk_kBH9FLtWz4SbmR6qCSR4yGvY5ypmetOC6-Wn6ihjuzR-ypo6C2sFDq_qAdfWWD-ZqbXp4PLrBREQXD0aD6syh4EndwlO-tV_rY_se5ccl3k/s1600/Zen_core_size.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Zen core size estimation based on Excavator data</td></tr>
</tbody></table>
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com46tag:blogger.com,1999:blog-3652428531631827883.post-52202205644827166782016-08-17T23:49:00.001+02:002016-08-17T23:57:09.429+02:00Some last chance pre Hot Chips speculation about ZenTL;DR: I made a new (stitched) Zeppelin die photo. AMD's datacenter APU might use multiple Zeppelin and Greenland dies. Zen's FPU might have some interesting and unique capabilities.<br />
<br />
There is less than one week left until AMD's Zen presentation at <a href="http://www.hotchips.org/" target="_blank">Hot Chips</a>. <a href="https://www.reddit.com/r/Amd/comments/4y4i2f/less_than_a_week_left_until_the_zen_presentation/" target="_blank">A redditor set up</a> <a href="http://www.timeanddate.com/countdown/generic?iso=20160823T1745&p0=1239&msg=ZEN+Presentation&font=slab&csz=1" target="_blank">this nice countdown</a>. As usual, AMD will not talk about final SKUs and clock frequencies. But they surely will give more details about individual microarchitectural features. While this would be the first chance to verify what has been posted <a href="http://dresdenboy.blogspot.de/2015/10/amds-zen-core-family-17h-to-have-ten.html" target="_blank">already ten</a> or <a href="http://dresdenboy.blogspot.de/2016/02/new-amd-zen-core-details-emerged.html" target="_blank">five months</a> ago on this blog, it will surely reduce the amount of features to be speculated about. In other words: this is a last chance to post some yet unpublished thoughts about the microarchitecture.<br />
<br />
<br />
For a start, you get this full Zen/Zeppelin die shot, created from multiple patches of the already known photo showing a part of a Zeppelin wafer:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioTnn9wdNvHA3sCAL4N2k2ef2i4kHG-0LI0ck0gh-uDLsWs78yr-YhPBuHU-2b2Q88i6vbRqMzJHbt_ZA4qtwKU30doYjYGvkfvSPTGPQPUD47yEsaaiugoERzqvGlkdJb3fvt0HcBpC0/s1600/Zeppelin_Die_stitched_labelled.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="293" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioTnn9wdNvHA3sCAL4N2k2ef2i4kHG-0LI0ck0gh-uDLsWs78yr-YhPBuHU-2b2Q88i6vbRqMzJHbt_ZA4qtwKU30doYjYGvkfvSPTGPQPUD47yEsaaiugoERzqvGlkdJb3fvt0HcBpC0/s640/Zeppelin_Die_stitched_labelled.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Labelled Zeppelin die photo (stitched)</td></tr>
</tbody></table>
Due to some missing reference, it is difficult to find the correct aspect ratio of the die. Scaled the way as shown above, it looks roughly "right" and also matches Hans de Vries' corrected image.<br />
<br />
In the past I estimated the die size to be about roughly 160 mm² based on what's in the core, and how other components might scale. When matching this die shot's DDR PHY to that of Skylake, I get roughly 200 mm² (assuming a good guess of the aspect ratio and roughly similar DDR PHY area). So I wouldn't be surprised, if Zeppelin is somewhere in this range 160-200 mm².<br />
<br />
<h3>
GMI-Links and the datacenter APU</h3>
<h3>
</h3>
AMD's GMI links (Global Memory Interconnect) are already known since Fudzilla mentioned them <a href="http://fudzilla.com/news/processors/38381-amd-s-new-interconnect-tech-is-coherent-fabric" target="_blank">here</a>. Soon afterwards <a href="http://www.fudzilla.com/news/processors/38402-amd-s-coherent-data-fabric-enables-100-gb-s" target="_blank">they posted</a> a slide, which likely shows a schematic view of AMD's planned datacenter APU. This slide was the base for creating the picture below. There I noticed the placement of the orange lines in the center of the Zeppelin and Greenland dies. As "Data Fabric" is written in the same color, the horizontal lines likely mean the same.<br />
<br />
So what does this tell us? Well, it looks like both the CPU part and the GPU part do consist of two dies each, which are also connected via GMI. If you already heard about the distributed memory controller in Zen based processors (mentioned in combination with a directory based coherency protocol on LinkedIn), all this makes sense. Knowing the leaked die photo, as shown above, it is not wrong to assume, that the two GMI link structures (GMI-Link #0 and #1) actually comprise of four links. This would be enough to connect two Zeppelin dies with two GMI links to get access to the two distributed memory controllers (and two DDR4 channels provided by them) on the other die. Two more links provided by each die go to the two Greenland dies, which in turn might also have four GMI links each. Each of the GPU dies might just have one HBM PHY. Of course, the shown Greenland GPU might just be a monolithic die sitting on the interposer. But while we are at it, an interposer would be a perfect way to stitch multiple dies together - something, that is expected to come to a greater extent with Navi.<br />
<br />
This would provide a lot of flexibility in configuring different processors from a small set of dies: one 8C Zeppelin die and probably just one Greenland die. One important reason for this would be costs for different designs, which are growing with each new process node.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqqfyMlivSk9I9kkGz1Mm5PzzO-OvKxeNXJdbaXu_iBAkV50SKsSV00eFZw1qp3a_N3_AvUSZiA7hhXTnff9Ix3CYX_Yl6HGP3xDIik8eypIXiP8pMZ7-Szva-QIoXc0mgZ_zfJXSS8Ik/s1600/Zen+APU+DF.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="478" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqqfyMlivSk9I9kkGz1Mm5PzzO-OvKxeNXJdbaXu_iBAkV50SKsSV00eFZw1qp3a_N3_AvUSZiA7hhXTnff9Ix3CYX_Yl6HGP3xDIik8eypIXiP8pMZ7-Szva-QIoXc0mgZ_zfJXSS8Ik/s640/Zen+APU+DF.jpg" width="640" /></a></div>
<br />
<h3>
Floating Point Unit</h3>
One of the more interesting parts of the Zen microarchitecture is the four-wide FPU. As the GCC patch suggests (by decoding type "single" or "double"), the FPU's native width is 128 bit for SIMD operations. A different patch mentioned a 3 cycle latency for cache accesses by the FPU. With a base L1D$ latency of 4 cycles indicated by the patches, this would mean a total of 7 cycles latency for FP memory accesses. This is likely the cost for going through the FX unit ("fixed point"), which contains the load store unit responsible for L1 data cache accesses. I won't go through the full details of the patches regarding all the different instructions. Let me point you to a wonderful CPU chart found at <a href="http://instlatx64.atw.hu/" target="_blank">InstLatX64</a>, which also includes Zen resp. Zeppelin, and Looncraz' <a href="http://looncraz.net/ZenAssignments.html" target="_blank">instruction mapping table</a>.<br />
<br />
But two things stood out about the MUL instructions:<br />
<ul>
<li>In early patches, FMA was displayed as using a combination of a FMUL pipeline (fp0/fp1) and the second FADD pipeline (fp3). This led me to the assumption, that we might see an incarnation of the bridged FMA here. Later this patch info has been changed, so that FMA instructions would run through the FMUL pipelines only </li>
<li>(SSE) FMUL and SSE IMUL instructions seem to occupy specific stages in the corresponding pipelines for more than one cycle. This means, throughput would be lower than 1 per pipeline. In the GCC patches this is specified as a times symbol, for example "fp0*3". However, this is not the case for FMA instructions, which could be related to a special treatment (due to the bridge), which might skip some to-be-iterated stage. We might learn a bit more about that next week.</li>
</ul>
One reason for that might be Zen's cat core heritage. To be more power efficient, cat cores use a "rectangular" or "iterative" multiplier. This means, it is reduced in depth, so that it can do 32bit FP multiplications at max throughput, but becomes slower, the wider the FP numbers are (64bit and 80bit). This is caused by the need to do multiple iterations in the multiplier array to produce all needed partial products, which become more, the wider the numbers are. This saves a lot of power and area, while still maintaining full throughput for a lot of FP/SIMD code (incl. games), which uses single precision. Also often used double precision has a lower throughput, which doesn't cause much of a performance hit with cat cores, as a lot of code even has more FADDs than FMULs. It typically costs a few percent with DP code for a nice power efficiency improvement.<br />
<br />
Another aspect is, that in case of a bridged FMA (or something similar, see below), the FPU wouldn't need that many FPRF read ports, as during doing a FMA operation, a first unit (FMUL) reads the two multiplicands of an FMA instruction, while a second unit (FADD) reads the addend with its own ports and finishes the FMA operation by doing the addition, normalization, and rounding. I think it is interesting to note, that several cat core related patents covering a FMA unit did show a delayed read of the addend.<br />
<br />
Since Zen will come with a lot of cores (especially the datacenter variants with up to 32 cores), AMD's (or Jim Kellers?) choice might have been to cut the per core power consumption for higher total core counts. Instead of making the whole core weaker, they seemingly decided to avoid hardware support for wide SIMD. This way, there is no need for 256b datapaths from L1D$ to the execution units, 256b wide registers, and of course 256b wide execution units. This already saves some power, as can be derived from the following chart, taken from the paper <a href="http://kentcz.com/downloads/P149-ISCA14-Preprint.pdf" target="_blank">"Improving the Energy Efficiency of Big Cores"</a> (PDF):<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUUHE_xQy5OJ0ns0fNCJIClvv6pLalOof2DpHaI1DP2x33a9nKvL3yU3hf5FlCN5v3R0LzW3VIVbiaalLJ92RPXCjR4DyPcHlCSFqW9tEmVvut7AKNxdNQ7pkQGncgePEYe8p9WqOcMz0/s1600/intelpoweripc.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="392" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUUHE_xQy5OJ0ns0fNCJIClvv6pLalOof2DpHaI1DP2x33a9nKvL3yU3hf5FlCN5v3R0LzW3VIVbiaalLJ92RPXCjR4DyPcHlCSFqW9tEmVvut7AKNxdNQ7pkQGncgePEYe8p9WqOcMz0/s640/intelpoweripc.png" width="640" /></a></div>
<br />
Similar to SIMD execution width, multipliers are still contributing a large part to a FPU's power consumption at full throughput, so AMD might have cut that further to use (updated) iterative multipliers as found in the cat cores. Maybe this is the reason, that there are two FMUL units in a single core at all, as the construction core line has shown, that AMD avoided to have that many FMUL/FMA units in a single core. There are other nice effects, like a reduction in voltage droops, which were the <a href="http://www.realworldtech.com/steamroller-clocking/" target="_blank">next big thing in Steamroller</a>, and are still being handled by Sam Naffziger's "Voltage Droop Mitigation" in Carrizo, Bristol Ridge, and <a href="https://translate.google.com/translate?sl=ja&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2Fcolumn%2Fkaigai%2F1010459.html&edit-text=" target="_blank">even Polaris</a>. An <a href="http://dl.acm.org/citation.cfm?id=2561896" target="_blank">AMD paper</a> described, how researchers were able to increase the base clock frequency of an Orochi processor by 400MHz and higher simply by reducing the throughput of heavy FP ops like FMUL. A FMUL implementation with an iterative multiplier would have a similar effect already built in.<br />
<br />
But that's not all. AMD Research lists a paper called "REEL: reducing effective execution latency of floating point operations", which (for many at least as abstract) can be found <a href="http://dl.acm.org/citation.cfm?id=2648716" target="_blank">here</a>. In this paper, researchers describe a novel FPU, which contains some additional registers located in one pipeline stage before round and normalization for later reuse. With a modified scheduler, it is possible, to significantly reduce the effective execution latency of a chain of dependent instructions. This happens by forwarding intermediate results from the internal micro register file. One important aspect of floating point performance is execution latency, as many calculations found in typical code have a low ILP (instruction level parallelism). In these cases, reducing these latencies is important. You may compare some of Zen's latencies in the CPU chart mentioned above. But on top of that, a FPU like described in REEL, would help even further. FMA hasn't explicitly been discussed in the paper, but the way, how the FPU works, there is even kind of an inherent FMA execution (kind of fusion) for dependent FMUL/FADD instructions.<br />
<br />
<h3>
Remaining things</h3>
<br />
What else could be shown at Hot Chips for Zen? Based on presentations and patents, I wouldn't be surprised about:<br />
<ul>
<li>a package level integrated voltage regulator, or maybe even a FIVR</li>
<li>per thread priorities for a more efficient SMT implementation in cases of differently prioritized threads (e.g. Prime95 in background and a game in foreground)</li>
<li>finally a working ASF/transactional memory implementation, which becomes increasingly important for higher core counts</li>
<li>more efficient address handling (esp. of stack addresses for accessing a stack cache) to reduce AGU usage</li>
<li>dual front ends in the future for an increasingly powerful execution back end</li>
<li>future application of die stacking (2.5D, 3D) and PIM</li>
<li>interesting network on chip topologies for 16 and 32 cores like <a href="http://www.eecg.toronto.edu/~enright/Kannan_MICRO48.pdf" target="_blank">"ButterDonut"</a></li>
<li>uOp and stack caches</li>
<li>reduced branch misprediction penalty thanks to checkpointing or fast rollback of executed instructions</li>
<li>FMUL/FADD fusion (to handle them via FMA operations)</li>
</ul>
This is, what I wanted to get out before enjoying this year's Hot Chips' Zen revelations!<br />
<br />
The next article on this blog will be about Zen clock frequency and performance projections, as more information became available. BTW, have you seen <a href="http://excavator.looncraz.net/" target="_blank">Looncraz' Zen analysis</a> at the end of his XV article yet?Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com24tag:blogger.com,1999:blog-3652428531631827883.post-82560627615710789832016-08-08T17:30:00.000+02:002016-08-11T22:04:00.747+02:00Some AMD Zen leaks (ES clocks, PCI info, Rambus DDR PHY, Roadmaps) [UPDATED]<span style="font-family: inherit; font-size: small;">Update: Small corrections, comments on PCIe dump<span style="font-family: inherit;"><span style="font-family: inherit;">, AoTS leaks, link to more slides added.</span></span></span><br />
<span style="font-family: inherit; font-size: x-small;"><span style="font-size: small;">TL;DR: <span style="font-family: inherit;">First Zen OPN and PCIe info leaked<span style="font-family: inherit;">. Additionally I do a recap of some other <span style="font-family: inherit;">recent leaks<span style="font-family: inherit;">.</span></span></span></span></span></span><br />
<br />
<span style="font-family: inherit;">Planet3DNow! forum user "Crashtest" <a href="http://www.planet3dnow.de/vbulletin/threads/421433-AMD-Zen-14nm-8-Kerne-95W-TDP-DDR4?p=5109711&viewfull=1#post5109711" target="_blank">posted a Zen ES OPN and PCI device info</a> (behind the spoiler button), which somehow landed in the CPU-Z and SIV databases.</span><br />
<br />
<span style="font-family: inherit;">So the OPN is "</span><b>1D2801A2M88E4_32/28_N</b>". Using the already known schema, "D" stands for desktop, "28" for the base clock frequency (2.8GHz), the first "8" of "88" for the number of cores. And more clearly, "32/28" stand for turbo boost frequency (3.2GHz), and the base clock again (2.8GHz). This matches the information given for the 8C DT ES in an <a href="https://forums.anandtech.com/threads/new-zen-microarchitecture-details.2465645/page-89#post-38363321" target="_blank">AnandTech forum posting</a> recently: <br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"></span>"The most exciting part is core clock. The 8c/95W variant's base clock is
<b>2.8GHz</b>, all core boost is 3.05GHz and maximum boost is <b>3.2GHz</b>." </blockquote>
This hasn't been confirmed in this way before (except that I heard it is true). So until now there was nothing available, that actually supported the information posted there.<br />
<br />
The PCI information found in the SIV database looks as follows: <br />
<blockquote class="tr_bq">
<span style="font-size: x-small;"><span style="font-family: "courier new" , "courier" , monospace;">Bus-Numb-Fun IRQ Vendor-Dev-Sub_OEM-Rev Class (9:255) Vendor and Device Description Showing 39 of 39<br />[0 - 00 - 0] 1022-1450-14501022-00 Host Bridge AMD<br />[0 - 01 - 0] 1022-1452-00000000-00 Host Bridge AMD<br />[0 - 01 - 2] 1022-1453-00000000-00 PCI Bridge (0-1) x4 (x4) AMD<br />[0 - 02 - 0] 1022-1452-00000000-00 Host Bridge AMD<br />[0 - 03 - 0] 1022-1452-00000000-00 Host Bridge AMD<br />[0 - 04 - 0] 1022-1452-00000000-00 Host Bridge AMD<br />[0 - 07 - 0] 1022-1452-00000000-00 Host Bridge AMD<br />[0 - 07 - 1] 1022-1454-00000000-00 PCI Bridge (0- x16 (x16) AMD<br />[0 - 08 - 0] 1022-1452-00000000-00 Host Bridge AMD<br />[0 - 08 - 1] 1022-1454-00000000-00 PCI Bridge (0-9) x16 (x16) AMD<br />[0 - 20 - 0] 1022-790B-790B1022-59 SMBus Controller AMD<br />[0 - 20 - 3] 1022-790E-790E1022-51 ISA Bridge AMD<br />[0 - 20 - 6] 1022-7906-79061022-51 SD Host DMA Controller AMD<br />[0 - 24 - 0] 1022-1460-00000000-00 Host Bridge AMD Summit Ridge (K17) Processor Link Control<br />[0 - 24 - 1] 1022-1461-00000000-00 Host Bridge AMD Summit Ridge (K17) Processor Address Map Configuration<br />[0 - 24 - 2] 1022-1462-00000000-00 Host Bridge AMD Summit Ridge (K17) Processor DRAM Controll<br />[0 - 24 - 3] 1022-1463-00000000-00 Host Bridge AMD Summit Ridge (K17) Processor Miscellaneous Control<br />[0 - 24 - 4] 1022-1464-00000000-00 Host Bridge AMD Summit Ridge (K17) Processor Link Control<br />[0 - 24 - 5] 1022-1465-00000000-00 Host Bridge AMD Summit Ridge (K17) Processor Function 5 Configuration<br />[0 - 24 - 6] 1022-1466-00000000-00 Host Bridge AMD Summit Ridge (K17) Processor Function 6 Configuration<br />[0 - 24 - 7] 1022-1467-00000000-00 Host Bridge AMD Summit Ridge (K17) Processor Function 7 Configuration<br />[1 - 00 - 0] 1022-43B9-11421B21-02 XHCI Controller x4 (x4) AMD Promotory USB 3.1 XHCI Host Controller<br />[1 - 00 - 1] 1022-43B5-10621B21-02 SATA (AHCI 1.0) x4 (x4) AMD<br />[1 - 00 - 2] 1022-43B0-00000000-02 PCI Bridge (1-2) x4 (x4) AMD<br />[2 - 00 - 0] 1022-43B4-00000000-02 PCI Bridge (2-3) x1 (x1) AMD<br />[2 - 01 - 0] 1022-43B4-00000000-02 PCI Bridge (2-4) x1 (x1) AMD<br />[2 - 02 - 0] 1022-43B4-00000000-02 PCI Bridge (2-5) x1 (x1) AMD<br />[2 - 03 - 0] 1022-43B4-00000000-02 PCI Bridge (2-6) x1 (x1) AMD<br />[2 - 04 - 0] 1022-43B4-00000000-02 PCI Bridge (2-7) x0 (x4) AMD<br />[3 - 00 - 0] 14E4-1687-168714E4-10 Ethernet Controller x1 (x1)Broadcom NetXtreme BCM5762 Gigabit Ethernet PCIe<br />[3 - 00 - 1] 14E4-1640-164014E4-10 SD Host DMA Controller x1 (x1)Broadcom<br />[5 - 00 - 0] 1002-68F9-010E1002-00 VGA Controller x1 (x16) AMD Cedar Pro [Radeon HD 5450/Radeon HD 6350] [GPU-0]<br />[5 - 00 - 1] 1002-AA68-AA681002-00 High Def Audio x1 (x16) AMD Cedar/Park HDMI Audio<br />[8 - 00 - 0] 1022-145A-145A1022-00 Other (0x130000) x16 (x16) AMD<br />[8 - 00 - 2] 1022-1456-14561022-00 Other Encryption x16 (x16) AMD<br />[8 - 00 - 3] 1022-145C-145C1022-00 XHCI Controller x16 (x16) AMD<br />[9 - 00 - 0] 1022-1455-14551022-00 Other (0x130000) x16 (x16) AMD<br />[9 - 00 - 2] 1022-7901-79011022-51 SATA (AHCI 1.0) x16 (x16) AMD<br />[9 - 00 - 3] 1022-1457-14571022-00 High Def Audio x16 (x16) AMD<br /><br />Total of 7 PCI buses and 39 PCI devices in 0.040 seconds.</span></span></blockquote>
<div style="text-align: right;">
<span style="font-size: x-small;"><span style="font-family: inherit;">Source: <span style="font-family: inherit;">SIV</span> database</span></span></div>
<br />
<b>Update #1:</b> As "Crashtest" explains in a <a href="http://www.planet3dnow.de/vbulletin/threads/421433-AMD-Zen-14nm-8-Kerne-95W-TDP-DDR4?p=5110384&viewfull=1#post5110384">later posting</a>, the respective Summit Ridge system (w/ Myrtle mainboard) seems to have at least 36 PCIe lanes. According to him, the listed configuration seems to be a bit chaotic. BTW, "Promotory" should actually be written "Promontory".<br />
<br />
<b>Update #2</b>: Thanks to the OPN, Planet3DNow! user "BoMbY" identified
some <b>Ashes of the Singularity benchmark results</b>, which were run on two different
Zen engineering samples. One had the same OPN, while the other had a slightly different
one ("2D" instead of "1D"). As they've been removed from the AotS
database, you can find them archived <a href="http://www.planet3dnow.de/vbulletin/threads/421433-AMD-Zen-14nm-8-Kerne-95W-TDP-DDR4?p=5110549&viewfull=1#post5110549" target="_blank">here</a>.<br />
<br />
<span style="font-family: inherit;">Next there was a <a href="http://www.bitsandchips.it/52-english-news/7322-amd-will-probably-use-the-ddr4-phy-of-rambus-in-zen" target="_blank">BitsAndChips article</a> about the likely provider of the DDR4 PHY found on Zen based processors: Rambus. That speculation is based on the given details the author learned from his sources, which fit well to what Rambus <a href="http://www.design-reuse.com/news/40258/rambus-r-ddr4-phy-globalfoundries-14nm-lpp.html" target="_blank">recently announced</a> regarding their 3200 Mbps DDR4 PHY available for Globalfoundries' 14LPP process. You can learn a bit more about their technology <a href="https://www.rambus.com/memory-and-interfaces/r-ddrn-phys/r-ddr4-phy/" target="_blank">here</a>.</span><br />
<span style="font-family: inherit;"></span><br />
<span style="font-family: inherit;">Another interesting bit of info are <a href="http://semiaccurate.com/forums/showthread.php?t=9270" target="_blank">two AMD roadmaps</a>, which look real. But as one recently could see with this <a href="http://imgur.com/gallery/VUz9G" target="_blank">Athlon X8K die shot</a> <a href="https://www.reddit.com/r/Amd/comments/4vujbb/athlon_x8k_99_octacore/" target="_blank">posted at Reddit</a>, even the quality of die shot fakes can be rather high (also see my analysis there). In that case the creator of the die shot wrote me, that he actually just tried to check the viability of such a product regarding die size and thus processing costs. Back to the roadmaps.</span><br />
<br />
<span style="font-family: inherit;">For 2017 they show:</span><br />
<ul>
<li><span style="font-family: inherit;">Raven Ridge APUs for the FP5 socket (4C/8T, <=12 gfx CUs, 4-35W TDP)</span></li>
<li><span style="font-family: inherit;">higher TDP models (65-95W) for the AM4 socket (also 4C/8T and an unknown number of gfx CUs)</span></li>
<li><span style="font-family: inherit;">also AM4 based Summit Ridge CPUs with 8C/16T and TDPs of 65 to 95W</span></li>
</ul>
<span style="font-family: inherit;">Most of the boxes are marked as "AMD PRO", which usually stands for a separate <a href="http://www.anandtech.com/show/9685/amd-pro-mobile-apu-carrizo-a12-8800b" target="_blank">series of products</a> targeted at commercial customers. Due to special certification programmes, perhaps also additional testing, and of course the integration in ready to ship OEM hardware, these products might hit the shelves a bit later than consumer variants.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">There is also a notable difference in the listed processes: "14nm SoC" for Raven Ridge, and "14nm FinFET" for Summit Ridge. I assume, that the "14nm SoC" process might refer to a different metal layer density, as recently covered in <a href="https://translate.google.com/translate?sl=ja&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http://pc.watch.impress.co.jp/docs/column/kaigai/1013752.html&edit-text=" target="_blank">an article by Hiroshige Goto</a> </span><span style="font-family: inherit;"><span style="font-family: inherit;">(<a href="http://pc.watch.impress.co.jp/docs/column/kaigai/1013752.html" target="_blank">Japanese</a>) </span>about APUs and AMD's FinFET efforts. Thus "FinFET" could stand for less dense lower metal layers, which would allow for somewhat higher clock speeds due to lower wire delays.</span><br />
<span style="font-family: inherit;"><br /></span>
A note on the slides: I saw some unusual pixel patterns and spacings in the "14nm SoC" and "14nm FinFET" boxes (aside from different sizes). I'd expect a scaled, interpolated PowerPoint slide to show subpixel positioning of single characters. But I saw only pixel exact 1 or 2 pixel spacings with exactly similar interpolated pixels around the characters. I'll try to reproduce this in PPT. <br />
<br />
In the end, these slides (if real) might mean, that there is no desktop Zen available in 2016 (even not as the promised sampling at the end of the year). But that is not for sure, yet. My own GCC patch based launch speculation gave a rough launch date range <a href="http://dresdenboy.blogspot.de/2015/10/how-many-days-until-zen.html">between 10/2016 and 05/2017</a>.<br />
<br />
<b>Update #3</b>: You can find the complete two slides and an additional one <a href="https://forums.anandtech.com/threads/new-zen-microarchitecture-details.2465645/page-105#post-38414961" target="_blank">here</a>. These don't look like being faked, although some details look a bit awkward. But this might be attributed to a smaller target audience (I suppose decision makers with more interests in dates and specs).Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com7tag:blogger.com,1999:blog-3652428531631827883.post-40441236164221002562016-05-23T00:59:00.000+02:002016-05-23T01:14:58.395+02:00First AMD Summit Ridge Wafer Photo spotted<span style="font-family: inherit;">If you are into die photos like me, you'll certainly be excited about this one, which <a href="http://semiaccurate.com/2016/05/22/38688/">has been spotted</a> by SemiAccurate's Thomas Ryan, when many (including me) didn't notice it while glancing over this particular slide (lower left corner):</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://pics.computerbase.de/7/2/4/4/4/3-1080.266527377.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="370" src="https://pics.computerbase.de/7/2/4/4/4/3-1080.266527377.png" width="640" /></a></div>
<br />
<div style="text-align: right;">
<span style="font-family: inherit;">Source: </span><a href="https://www.computerbase.de/2016-05/amd-prozessor-bristol-ridge-zen/" style="font-family: inherit;">ComputerBase</a></div>
<span style="font-family: inherit;"><br /></span>
It apparently shows Zen based Summit Ridge dies on a wafer and has been grabbed by ComputerBase, which published it in an <a href="http://www.computerbase.de/2016-05/amd-prozessor-bristol-ridge-zen/">article</a> covering AMD's <a href="https://amd.onlineshareholdermeeting.com/vsm/web?pvskey=AMD">Annual Stockholder Meeting</a> and some interesting updates in their <a href="http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MzM5NDM5fENoaWxkSUQ9LTF8VHlwZT0z&t=1&cb=635994397107592147">Investor Presentation slidedeck</a>.<br />
<span style="font-family: inherit;"><br /></span>Here is a zoomed variant:<br />
<blockquote class="twitter-tweet" data-conversation="none" data-lang="de">
<div dir="ltr" lang="en">
<a href="https://twitter.com/Dresdenboy">@Dresdenboy</a> Okay, that would make sense. I attempted to make a better quality version of the wafer shot. <a href="https://t.co/nLVPMZGTcY">pic.twitter.com/nLVPMZGTcY</a></div>
— Thomas Ryan (@UncheckedError) <a href="https://twitter.com/UncheckedError/status/734494864033742848">22. Mai 2016</a></blockquote>
<span style="font-family: inherit;">One half of the die would look like this after some perspective correction:</span><br />
<span style="font-family: inherit;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0gVo9HJoTph4Js_1bQ_7RB9icUPyZlLSDdLq9TgeW4EvIFDV5YCtXc7yWxXx0LvSz0g0vHB_2DdekrlCbImf4e019CjU1iz4uiMjCHn-mYebR5WV0vq8RiyoLhtw3UBNG361X2rZ2h5M/s1600/Zen+die+2a_perspective_corrected_shrunk.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0gVo9HJoTph4Js_1bQ_7RB9icUPyZlLSDdLq9TgeW4EvIFDV5YCtXc7yWxXx0LvSz0g0vHB_2DdekrlCbImf4e019CjU1iz4uiMjCHn-mYebR5WV0vq8RiyoLhtw3UBNG361X2rZ2h5M/s1600/Zen+die+2a_perspective_corrected_shrunk.png" /></a></div>
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">There you can see one core complex with four cores and likely 8 MB of L3 cache.</span><br />
<span style="font-family: inherit;"><br /></span>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
<span style="font-family: inherit;">The mentioned slidedeck in a <a href="http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MzM5MzMxfENoaWxkSUQ9LTF8VHlwZT0z&t=1&cb=635992964179233292">somewhat older version</a> also contained a rough comparison of the performance between Summit Ridge (8 Zen core variant) and Orochi (could be anything from Bulldozer based FX-81xx to Orochi revision C "Vishera", also known as FX-83xx with 8 cores). This has been changed to Excavator vs. Zen in the <a href="http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MzM5NDM5fENoaWxkSUQ9LTF8VHlwZT0z&t=1&cb=635994397107592147">latest version</a> of the slides, as linked above. I stitched both comparisons together:</span><br />
<span style="font-family: inherit;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMf15QHdVTiOehyphenhyphenXLsfuJaUPvgrQlRkTiJNrSplRAL4A-y7Sn1WNZjA7AskUuGqu0a6jfMF_7X5cu346jxw_Wtv9k0mSJSmGOi10SKU-mcwJVKW2Mg5MkCdi4ArRx-pMBm15AfnWFGWwM/s1600/Zen+Perf.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMf15QHdVTiOehyphenhyphenXLsfuJaUPvgrQlRkTiJNrSplRAL4A-y7Sn1WNZjA7AskUuGqu0a6jfMF_7X5cu346jxw_Wtv9k0mSJSmGOi10SKU-mcwJVKW2Mg5MkCdi4ArRx-pMBm15AfnWFGWwM/s640/Zen+Perf.png" width="640" /></a></div>
<span style="font-family: inherit;"><br /></span>Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com10tag:blogger.com,1999:blog-3652428531631827883.post-77467332003898576332016-02-29T20:31:00.002+01:002016-03-01T11:22:11.523+01:00New AMD Zen core details emergedJust one week after my last blog posting, providing a hint of the maximum number of Zen cores supported per socket, a news wave about details of Zen based server processors given in the presentation of a CERN researcher hit the web. The guy works in the institution's Platform Competence Centre (PCC) and manages integration of predominantly prototype hardware according to his <a href="http://openlab.web.cern.ch/about/people/liviu-v%C3%A2lsan">CERN profile</a>. So it can be assumed, that anything he says about server platforms might have been provided by representatives coming from the different processor and server OEMs. The 8 memory channels haven't been mentioned before in a leak or patch. And the 32 core number is not related to my posting, as the CERN talk has been held on 29th of January while I published my posting (unaware of the talk) on the 1st of February, after first mentioning the patch <a href="http://semiaccurate.com/forums/showpost.php?p=250573&postcount=1541">already in December</a>.<br />
<br />
Now a new series of patches provides further information about the Zen core's IP blocks. They've been <a href="https://lkml.org/lkml/2016/2/16/892">posted</a> on 16/02/16 on the Linux kernel mailing list by an AMD employee, after an <a href="http://www.spinics.net/lists/linux-edac/msg05493.html">earlier round of patches</a> in January, which even mention a "ZP" target, very likely being the abbreviation for "Zeppelin". The more recent patches cover additions to AMD's implementation of a scalable Machine Check Architecture (MCA), and handling of deferred errors. This is implemented in the Linux EDAC kernel module, which is responsible for hardware error detection and correction. The <a href="https://lkml.org/lkml/2016/2/16/888">most interesting patch</a> contains following sections, with some details highlighted:<br />
<br />
<blockquote class="tr_bq">
<pre itemprop="articleBody">+/*
+ * Enumerating new IP types and HWID values
+ * in ScalableMCA enabled AMD processors
+ */
+#ifdef CONFIG_X86_MCE_AMD
+enum ip_types {
+ F17H_CORE = 0, /* Core errors */
+ DF, /* Data Fabric */
+ UMC, /* Unified Memory Controller */
+ FUSE, /* FUSE subsystem */
+ PSP, /* Platform Security Processor */
+ SMU, /* System Management Unit */
+ N_IP_TYPES
+};
+enum core_mcatypes {
+ LS = 0, /* Load Store */
+ IF, /* Instruction Fetch */
+ L2_CACHE, /* L2 cache */
+ DE, /* Decoder unit */
<span style="color: #cc0000;"><b>+ RES, /* Reserved */</b></span>
+ EX, /* Execution unit */
+ FP, /* Floating Point */
+ L3_CACHE /* L3 cache */
+};
+
+enum df_mcatypes {
+ CS = 0, /* Coherent Slave */
+ PIE /* Power management, Interrupts, etc */
+};
+#endif</pre>
</blockquote>
<br />
The interconnect subsystem is called "Data Fabric", which knows so called coherent slaves according to the last enumeration list. The "FUSE subsystem" might be replaced by something else like "Parameter block", as it just means a block managing the processor's configuration.<br />
<br />
The second list of enumerations contains a blocks found in the Zen core or close to it. I think, the highlighted "RES" element might actually stand for a real IP block, as it doesn't make much sense to have it sitting inmidst the other elements and not at the end. According to some other code in the patch, the L2 cache is seen as part of the core, while the L3 cache is not (as expected):<br />
<br />
<blockquote class="tr_bq">
<pre itemprop="articleBody">+ case F17H_CORE:
+ pr_emerg(HW_ERR "%s Error: ",
+ <span style="color: #cc0000;"><b>(mca_type == L3_CACHE) ? "L3 Cache" : "F17h Core");</b></span>
+ decode_f17hcore_errors(xec, mca_type);
+ break;</pre>
</blockquote>
<br />
Now let's go through some of the error string lists, beginning with those dedicated to the load/store unit:<br />
<br />
<blockquote class="tr_bq">
<pre itemprop="articleBody">+/* Scalable MCA error strings */
+
+static const char * const f17h_ls_mce_desc[] = {
+ "Load queue parity",
+ "Store queue parity",
+ "Miss address buffer payload parity",
+ "L1 TLB parity",
<span style="color: #cc0000;"><b>+ "", /* reserved */</b></span>
+ "DC tag error type 6",
+ "DC tag error type 1",</pre>
</blockquote>
<br />
This is the first of many lists containing error strings, in this case for the load/store unit. Similar to the enumeration above, there is a reserved element, possibly hiding something, as this is a public mailing list. The strings I left out don't contain any surprises compared to the Bulldozer family. But overall I get the impression, that AMD significantly improved the RAS capabilities, which are very important for server processors. The following block contains error strings related to the instruction fetch block ("if"):<br />
<br />
<blockquote class="tr_bq">
<pre itemprop="articleBody">+static const char * const f17h_if_mce_desc[] = {
+ "microtag probe port parity error",
+ "IC microtag or full tag multi-hit error",
+ "IC full tag parity",
+ "IC data array parity",
+ "Decoupling queue phys addr parity error",
<b><span style="color: #cc0000;">+ "L0 ITLB parity error",
+ "L1 ITLB parity error",
+ "L2 ITLB parity error",</span></b>
+ "BPQ snoop parity on Thread 0",
+ "BPQ snoop parity on Thread 1",
+ "L1 BTB multi-match error",
+ "L2 BTB multi-match error",
+};</pre>
</blockquote>
<br />
There is a new L0 ITLB, which is the only level 0 thing being mentioned so far, while VR World mentioned level 0 caches (besides other somewhat strange rumoured facts like no L3 cache in the APU variant - while this has been shown on the leaked Fudzilla slide). The only thing resembling such a L0 cache is a uOp cache, which has clearly been named in the new patch in a section related to the decode/dispatch block (indicated by "de"):<br />
<br />
<blockquote class="tr_bq">
<pre itemprop="articleBody">+static const char * const f17h_de_mce_desc[] = {
<span style="color: #cc0000;"><b>+ "uop cache tag parity error",
+ "uop cache data parity error",</b></span>
+ "Insn buffer parity error",
+ "Insn dispatch queue parity error",
+ "Fetch address FIFO parity",
+ "Patch RAM data parity",
+ "Patch RAM sequencer parity",
<span style="color: #cc0000;"><b>+ "uop buffer parity"</b></span>
+};</pre>
</blockquote>
<br />
There are strings for both a "uop cache" and a "uop buffer". So far I knew about this <a href="http://www.google.com/patents/US20140136822">uop buffer patent</a> filed by AMD in 2012, which describes different related techniques aimed at saving power, e.g. when executing loops or to keep the buffer physically small by leaving immediate and displacement data of decoded instructions in an instruction byte buffer ("Insn buffer") sitting between instruction fetch and decode. The "uop cache" clearly seems to be a separate unit. Even without knowing how many uops per cycle can be provided by that cache, it will help to save power and remove an occaisional fetch/decode bottleneck when running two threads. The next interesting block is about the execution units:<br />
<br />
<blockquote class="tr_bq">
<pre itemprop="articleBody">+static const char * const f17h_ex_mce_desc[] = {
+ "Watchdog timeout error",
+ "Phy register file parity",
+ "Flag register file parity",
+ "Immediate displacement register file parity",
+ "Address generator payload parity",
+ "EX payload parity",
<span style="color: #cc0000;"><b>+ "Checkpoint queue parity",</b></span>
+ "Retire dispatch queue parity",
+};</pre>
</blockquote>
<br />
Here is a first confirmation of a checkpoint mechanism. This has been described in several patents and might also be an enabler for hardware transactional memory, which has been <a href="http://developer.amd.com/community/blog/2009/06/15/just-released-advanced-synchronization-facility-asf-specification/">proposed in the form of ASF</a> back in 2009. Another use case is the quick recovery from branch mispredictions, where program flow can be redirected to a checkpoint created right before evaluating a difficult to predict branch condition.<br />
<br />
Let me continue with some random picks:<br />
<br />
<blockquote class="tr_bq">
<pre itemprop="articleBody">+ "L3 victim queue parity",
...
+ "Atomic request parity",
+ "ECC error on probe filter access",</pre>
<pre itemprop="articleBody">...</pre>
<pre itemprop="articleBody"><span style="color: #cc0000;"><b>+ "Error on GMI link",</b></span></pre>
</blockquote>
<br />
There is a confirmation of the "GMI link" mentioned on an already <a href="http://www.fudzilla.com/news/processors/38402-amd-s-coherent-data-fabric-enables-100-gb-s">leaked slide</a>, which mentioned a bandwidth of 25 GB/s per link. The term "Data Fabric" also has been used on that slide.<br />
<br />
When reporting about the 32 core support, I wrote that some patents used the same wording. It's actually "core processing complex" (CPC) and can contain multiple compute units (like Zen cores). So they are not the same. AMD patent filings using the term are <a href="http://www.freepatentsonline.com/y2015/0277521.html">US20150277521</a>, <a href="http://www.freepatentsonline.com/y2015/0120978.html">US20150120978</a>, and <a href="http://www.freepatentsonline.com/y2014/0331069.html">US20140331069</a>.<br />
<br />
Last but not least I have updated the Zen core diagram based on these new informations and some very likely related patents and papers:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL_gdJ-VjW7LFQNlzlgUiSj6vKHrjmPQfNuc-6jltx5pPG9dwfXVm5xnu2ahm4mWLeoKXYJeauUGHqqWockOXWLKmMzR0JlCca4Y9AicUxKMmITX2TRXX0mWOi1mFw8QcNFFDt5_3NrxY/s1600/Zen-Architektur+Core+V0.3.2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="627" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL_gdJ-VjW7LFQNlzlgUiSj6vKHrjmPQfNuc-6jltx5pPG9dwfXVm5xnu2ahm4mWLeoKXYJeauUGHqqWockOXWLKmMzR0JlCca4Y9AicUxKMmITX2TRXX0mWOi1mFw8QcNFFDt5_3NrxY/s640/Zen-Architektur+Core+V0.3.2.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKQaFqra0lCN_SdET5TQ9TZt_N1jblFH5iS1rQ4sRZtcBZ3NNkHC7OfFF5PGw2EYNrVc7hxXjvu5lTc3Uu2OoKn563B9xOqDP-q3oxBRQwSs-k966mvDe7uyTZV-xr2vVs-okFnVHARkE/s1600/Zen-Architektur+Core+V0.3.2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><br /></a></div>
<br />
Notable changes are:<br />
<ul>
<li>uOp Cache has been added based on the new patch</li>
<li>FMUL/FADD for FMAC pairing removed, based on <a href="https://patchwork.ozlabs.org/patch/582226/">some corrections</a> of the znver1 pipeline description.</li>
<li>4x parallel Page Table Walkers added, based on <a href="http://www.freepatentsonline.com/y2015/0121046.html">US20150121046</a></li>
<li>128b FP datapaths (also to/from the L1 D$) based on "direct" decode for 128b wide SIMD and "double" decode for 256b AVX/AVX2 instructions</li>
<li> 32kB L1 I$ has been mentioned in some patents. With enough ways, a fast L2$ and a uOp cache this should be enough, I think.</li>
<li>issue port descriptions and more data paths added</li>
<li>2R1W and 4 cycle load-to-use-latency added for the L1 D$ based on info found on a LinkedIn profile and the given cylce differences in the znver1 pipeline description</li>
<li>Stack Cache speculatively added based on patents and some interesting papers. This doesn't help so much with performance, but a lot with power efficiency.</li>
</ul>
It's still interesting, what the first mentioning of fp3 port for FMAC operations was good for. I
<a href="http://dresdenboy.blogspot.de/2015/10/amds-zen-core-family-17h-to-have-ten.html">thought, it was a typo</a>, but more of the kind "fp3" instead of "fp2" in one case. It could still be related to register file port usage and/or bridged FMA, but probably not that useful for telling the compiler. Due to the correction patch I'm still looking further into the FPU topic, as promised earlier. I'll cover that in a followup posting.<br />
<br />
Finally there is a hint at good hardware prefetcher performance (or bad interferences?), as AMD <a href="https://patchwork.ozlabs.org/patch/577588/">recommends </a>to switch off default software prefetching for the znver1 target in GCC.<br />
<br />
BTW have you ever heard of a processor core having <a href="https://www.google.com/patents/US20140297965">2 front ends and one shared back end</a>?<br />
<br />
Update: There is an update of the bespoken patches, posted on the same day as this blog entry. You can see it <a href="http://linux-kernel.2935.n7.nabble.com/PATCH-V2-0-5-Updates-to-EDAC-and-AMD-MCE-driver-td1318357.html">here</a>. So far I didn't see any significant additions other than cleanups and fixes.Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com62tag:blogger.com,1999:blog-3652428531631827883.post-32147535411388188792016-02-08T01:17:00.002+01:002016-02-09T08:57:45.356+01:00More AMD Bristol Ridge SKUs leaked<a href="https://twitter.com/I_biT_MySeLf">Kristian Gocnik (@I_biT_MySeLf)</a> tipped me off about new mobile Bristol Ridge SKUs, which appeared on usb.org as you can see [UPDATE: the entries have been removed now - visiting the pages may delete your only cached copy in the browser] <a href="http://www.usb.org/kcompliance/view/view_item?item_key=44fded3774c89b7955201646fa9e86c5137bcb38&referring_url=/kcompliance">here</a> and <a href="http://www.usb.org/kcompliance/view/view_item?item_key=edf8e2fbc15187c3d6f933ea30fd78d05609f539&referring_url=/kcompliance">here</a>. That's the same site, where the first Bristol Ridge SKU (FX-9830P) appeared on. I put this together with information found in the leaked slide by Benchlife.info, which you can find in <a href="http://dresdenboy.blogspot.de/2016/01/amd-a10-9600p-bristol-ridge-laptop-left.html">my blog post about a WEI result of an A10-9600P</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhB4-YHjJNrVmcd5U2oNombFg68RYHLBD1S4Q2krZNYoCZOGNJ5znriszBrAhOGQUUVwX4OIUTBVAZttIVp2rVZhWz8Qj9KkA7cy16GCIUHIkESOkRCIbjAV8q1wYJ47yc0Mdk0bikDsqg/s1600/Leaked+BR+FP4+OPNs.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Table with leaked mobile Bristol Ridge OPNs" border="0" height="249" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhB4-YHjJNrVmcd5U2oNombFg68RYHLBD1S4Q2krZNYoCZOGNJ5znriszBrAhOGQUUVwX4OIUTBVAZttIVp2rVZhWz8Qj9KkA7cy16GCIUHIkESOkRCIbjAV8q1wYJ47yc0Mdk0bikDsqg/s640/Leaked+BR+FP4+OPNs.png" title="Overview of leaked mobile Bristol Ridge OPNs" width="640" /></a></div>
<br />
Using the mobile Carrizo SKUs, the leaked A10-9600P clock, and some sorting, it was easy to map the SKUs to the leaked slide's data. Kristian Gocnik tried it independently and we got the same mapping, except for a consumer A8-9500P he speculatively derived from the pro model, but which is missing on usb.org. So the resulting table likely represents what AMD is going to release as mobile Bristol Ridge chips for the FP4 socket later this year.<br />
<br />
The model numbers likely simply jumped by one thousand from Carrizo's and an additional thirty points for the 35W variants. Carrizo's wide TDP ranges got split into 15W and 35W TDPs. This might help to avoid the confusion about 15W and 35W Carrizos laptops. The CPU base clocks jumped significantly, while CPU Turbo and (maximum) GPU clocks kind of matured with the fab process.<br />
<br />
A reason for the jump has been given by AMD at <a href="https://www.blogger.com/">ISSCC 2016</a>, as <a href="http://www.eetimes.com/author.asp?section_id=36&_mc=RSS_EET_EDT&doc_id=1328845&page_number=2">EE Times reported</a>:<br />
<blockquote class="tr_bq">
<i>"For its part, AMD engineers showed smart ways of squeezing as much as 15% more performance out of its Carrizo PC processor, simply by applying more aggressive power management to the 28nm design. The Bristol Ridge design was a study in using power management to overcome performance limits tied to heat, voltage and current."</i></blockquote>
Months after the first leaked WEI score, first true Bristol Ridge benchmarks will show, how this improvement translates into real world performance. Hopefully they get tested with dual channel memory, even if AMD or OEMs only provide single channel equipped/designed devices, as for the recent <a href="http://www.anandtech.com/show/10000/who-controls-user-experience-amd-carrizo-thoroughly-tested">AnandTech Carrizo review</a>.<br />
<br />
BTW, there are lots of fresh <a href="https://browser.primatelabs.com/geekbench3/search?q=family+21+model+112">Stoney Ridge Geekbench results</a> in the Primate Labs' database.<br />
<br />
Update: Of course, these are not OPNs, but SKUs. Added a warning as the linked usb.org entries are gone.Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com8tag:blogger.com,1999:blog-3652428531631827883.post-81120639051130779122016-02-01T01:54:00.001+01:002016-02-01T01:54:21.586+01:00AMD Zeppelin CPU codename confirmed by patch and perhaps 32 cores per socket for Zen based MPUs, too<span style="font-family: Arial, Helvetica, sans-serif;">The Zeppelin codename, first mentioned on a leaked slide shown by <a href="http://www.fudzilla.com/news/processors/38402-amd-s-coherent-data-fabric-enables-100-gb-s">Fudzilla</a>, has been identified as a "family 17h model 00h" CPU by <a href="https://lkml.org/lkml/2016/1/29/78">a patch on LKML.org</a>. The interesting parts of the patch are:</span><br />
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;"><span style="font-family: "courier new" , "courier" , monospace;"><b>AMD Zeppelin (Family 17h, Model 00h)</b> introduces an instructions</span><span style="font-family: "courier new" , "courier" , monospace;">retired performance counter which indicated by</span><span style="font-family: "courier new" , "courier" , monospace;">CPUID.8000_0008H:EBX[1]. And dedicated Instructions Retired register</span><span style="font-family: "courier new" , "courier" , monospace;">(MSR 0xC000_000E9) increments on once for every instruction retired.</span></span></blockquote>
<pre itemprop="articleBody"></pre>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="white-space: normal;">There might even be a meaning behind the similarity of parts of the "Zen" and "<b>Ze</b>ppeli<b>n</b>" codenames.</span></span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="white-space: normal;"><br /></span></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="white-space: normal;">An <a href="https://lkml.org/lkml/2015/11/3/634">older patch</a> on the same mailing list also gives a little more info about Zen:</span></span><br />
<pre itemprop="articleBody"><span style="font-family: "times new roman";"><span style="font-family: "times" , "times new roman" , serif; white-space: normal;">
</span></span></pre>
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;">On AMD Fam17h systems, the last level cache is not resident in </span><span style="font-family: "courier new" , "courier" , monospace;">Northbridge. Therefore, we cannot assign cpu_llc_id to same </span><span style="font-family: "courier new" , "courier" , monospace;">value as Node ID (as we have been doing currently)</span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;">We should rather look at the ApicID bits of the core to provide </span><span style="font-family: "courier new" , "courier" , monospace;">us the last level cache ID info. Doing that here.</span></blockquote>
<pre itemprop="articleBody"><span style="font-family: Arial, Helvetica, sans-serif; white-space: normal;">The most interesting part describes the way, how the last level cache (LLC) ID is being calculated for Zen based MPUs:</span></pre>
<pre itemprop="articleBody"></pre>
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;">+ core_complex_id = (apicid & ((1 << c->x86_coreid_bits) - 1))<b><span style="color: red;"> >> 3</span></b>;</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">+ per_cpu(cpu_llc_id, cpu) = (socket_id << 3) | core_complex_id;</span></blockquote>
<pre itemprop="articleBody"></pre>
<span style="white-space: normal;"><span style="font-family: inherit;">"Core complex" should be similar to "compute unit" and has been used in some AMD patents already. The expression marked in red means a shift right by 3, which equals a division by 8. So with two logical cores per physical core due to SMT, a core complex should contain four Zen cores and a shared LLC.</span></span><br />
<pre itemprop="articleBody"><span style="white-space: normal;"><span style="font-family: inherit;">
</span></span></pre>
<pre itemprop="articleBody"><span style="white-space: normal;"><span style="font-family: "times new roman";">
</span></span></pre>
<span style="font-family: inherit; white-space: normal;"><span style="font-family: inherit; white-space: normal;">The next line show</span><span style="font-family: inherit; white-space: normal;">s the socket ID being shifted left by 3, leaving 3 bits for the core complex ID, which suggests a maximum number of eight core complexes per socket, or <b>32</b> physical cores. This number should first be seen as a placeholder, but we've already seen rumours mentioning that many cores.</span></span><br />
<pre itemprop="articleBody"></pre>
Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com8tag:blogger.com,1999:blog-3652428531631827883.post-49343436746861124092016-01-05T01:54:00.000+01:002016-01-05T02:21:05.228+01:00AMD A10-9600P: A Bristol Ridge laptop left some tracesOne of my search strings got a hit today. Based on the already known model number 101 I found this Windows Experience Index CPU score of an AMD "A10-9600P" APU (Bristol Ridge). It's a quad core (2 modules) with 6 CUs and a reported base clock of 2.3GHz. A CPU score of 7.4 isn't that low, but doesn't tell us that much more, except that the system was able to finish the benchmark test. The result currently sits on page 7 of the filtered list linked by the table screenshot. You can also click the other images for the respective sources.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.drivermax.com/driver/vista-rating/index_cpu.php?&start=7&filter_name=&filter_min_CpuScore=7.3&filter_max_CpuScore=7.5"><img alt="http://www.drivermax.com/driver/vista-rating/index_cpu.php?&start=7&filter_name=&filter_min_CpuScore=7.3&filter_max_CpuScore=7.5" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtUupQCiCqB0jMphR23MG6M7gVlUt5CT6WhxDQQl80aD6a7PHlay4y_i8dX29nsNDVxiEj5Yf9s4EjdJ6wNWqNxOZjS7npouNkgBc7V9S4V0fABMXBzet5oDunDwPaHP_cvkRKEMUX6LY/s1600/AMD_Bristol_Ridge_WEI_Score_cut.png" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.drivermax.com/driver/laptop-rating/selvideo/Hewlett-Packard/InsydeH2O+EFI+BIOS/AMD+A10-9600P+RADEON+R5,+10+COMPUTE+CORES+4C%2B6G/pag0" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;" target="_blank"></a></div>
<div class="separator" style="clear: both; text-align: left;">
According to another page the listed model is a HP system, very likely a laptop.</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.drivermax.com/driver/laptop-rating/selvideo/Hewlett-Packard/InsydeH2O+EFI+BIOS/AMD+A10-9600P+RADEON+R5,+10+COMPUTE+CORES+4C%2B6G/pag0" style="margin-left: 1em; margin-right: 1em;"><img alt="http://www.drivermax.com/driver/laptop-rating/selvideo/Hewlett-Packard/InsydeH2O+EFI+BIOS/AMD+A10-9600P+RADEON+R5,+10+COMPUTE+CORES+4C%2B6G/pag0" border="0" height="64" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtCXq0zA0cL8aBSOEGHSuY2760Vw7bzXw8QPj7-AMDSJ3LpGcBOj3eK-GYmcykMWvhQUCq7p19H1zfjcO4R0sVhsheRmN7pf7KD5R2Jmj7fJro8jmsvWEOJgQVtLc1KWXNLh-lnZ33BSs/s640/AMD_Bristol_Ridge_OEM.png" width="640" /></a></div>
<br />
As can be seen in the leaked slide below, the found CPU might be the a quad core with a cTDP of 12-15W.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgW0G9CFkM6LHi71KCiN0sEh4i8J9j8-ZBvbtHM6-AkWHhyq7PQI-l6bjv05hzyPRnv3cvhWFRb5ID8dcHaQdh7EmAIQak6AyJbllivhSP1gTZkyYq6RBH1dGwthWJbmuKxIz7zdEqERlU/s1600/BRISTOL-RIDGE-SAMPLE-SPEC-FP4_marked.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgW0G9CFkM6LHi71KCiN0sEh4i8J9j8-ZBvbtHM6-AkWHhyq7PQI-l6bjv05hzyPRnv3cvhWFRb5ID8dcHaQdh7EmAIQak6AyJbllivhSP1gTZkyYq6RBH1dGwthWJbmuKxIz7zdEqERlU/s1600/BRISTOL-RIDGE-SAMPLE-SPEC-FP4_marked.jpg" /></a></div>
Source: <a href="https://benchlife.info/amd-will-rename-excavator-to-bristol-ridge-12082015/">https://benchlife.info/amd-will-rename-excavator-to-bristol-ridge-12082015/</a><br />
<br />
After the first listing of a Bristol Ridge SKU ("FX-9830P", thx <a href="https://twitter.com/Onkel_Dithmeyer">@Onkel_Dithmeyer</a>) and some BR ES <a href="http://wccftech.com/amd-am4-cpu-apu-motherboard/">traveling through the world</a>, we now have a first Bristol Ridge APUs reporting the final product OPN instead of a typical ES string. Perhaps this is a system to be shown at CES?<br />
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com6tag:blogger.com,1999:blog-3652428531631827883.post-82439994832307336862015-11-23T01:17:00.001+01:002015-11-23T01:17:01.003+01:00AMD K12 looks to be at least a 4-wide design with SMTAn <a href="http://ascii.jp/elem/000/001/006/1006883/" target="_blank">article about Zen and K12</a> by Yusuke Ohara gives a good overview of AMD's processor plans and a new and very interesting bit of information about AMD's high performance ARM design. As machine translators still struggle to provide clearly understandable translations of Japanese texts, multiple translators were tried and did not help. Therefore I asked the author to make sure that I got it right. He confirmed, that according to ARM officials, who are aware of the works of their architectural licensees, AMD is using at least a 4-wide design for their K12 core.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvBl8xnuNXCSUup558K8U60wgdlsmWgJ0VSFsH0-klcooryvFljY5XNL7aNyt9Igb4FPtoW7GjG_kHTgsjAcQzNzYB8ToNKdxyAqvAnRnrqlGk8ye0Y_pqDhI37JPD4u6rSITRB9wnhsM/s1600/AMD-ARM-K12-Core-High-Performance-Custom.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="359" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvBl8xnuNXCSUup558K8U60wgdlsmWgJ0VSFsH0-klcooryvFljY5XNL7aNyt9Igb4FPtoW7GjG_kHTgsjAcQzNzYB8ToNKdxyAqvAnRnrqlGk8ye0Y_pqDhI37JPD4u6rSITRB9wnhsM/s640/AMD-ARM-K12-Core-High-Performance-Custom.jpg" width="640" /></a></div>
<br />
<br />
<a href="http://techreport.com/review/26418/amd-reveals-k12-new-arm-and-x86-cores-are-coming" target="_blank">Jim Keller already said</a>, that the smaller decoders for ARM instructions would leave room to add some performance improving features compared to x86. He also mentioned "a bigger engine" than in Zen. Looking at the <a href="http://dresdenboy.blogspot.de/2015/10/amds-zen-core-family-17h-to-have-ten.html" target="_blank">microarchitecture diagram</a>, one might ask, how AMD would utilize all these execution hardware, especially if there would be even more units and maybe even more than four instructions fetched and decoded per cycle. And given its target market, which is servers and datacenters, this might include one important feature: SMT. Some already speculated about that based on expectations, but there is AMD patent application <a href="http://www.freepatentsonline.com/y2015/0121046.html" target="_blank">US20150121046</a>, which mentions SMT and its application in an AArch64 design very clearly and with many implementation details. This can be seen as an indicator of work being done for real products.<br />
<br />
If K12 is a 4-wide or even wider SMT design similar to Zen (which is "only" 4-wide), this would put some substance behind Keller's announcements, which suggested many similarities between both designs. This is supported by the fact, that one of the inventors listed in the patents (Marius Evers) seemingly worked on both cores. Many other patents by him also cover both ARM and x86. He was also involved in one patent filed in 2007, which described a way to add SMT to the front end of a Bulldozer like module. SMT is not only useful to utilize execution units, if there are many of them. It also helps by keeping them busy, if there are multi-cycle FP instructions, branch mispredictions, or cache misses.<br />
<br />
Of course, there are more differences between those two architectures than the ISAs alone, but many typical CPU components are either ISA-agnostic and reusable or could be adapted with much less effort than creating them from scratch. However, if it was done this way, such a strategy would not only have permitted AMD to make an efficient use of the limited R&D resources available, but it would have created a chance to produce a powerful ARM core for servers for an acceptable overhead. This is like applying SMT to R&D.<br />
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com73tag:blogger.com,1999:blog-3652428531631827883.post-14091842338572770202015-11-18T18:38:00.005+01:002015-11-18T18:38:54.686+01:00AMD Hierofalcon/Seattle shown at ARM TechConAMD presented some boards at ARM TechCon and thanks to <a href="http://armdevices.net/">ARMdevices.net</a> there are two videos covering that stuff.<br />
<br />
One <a href="http://armdevices.net/2015/11/16/amd-huskyboard-96boards-enterprise-edition-explained-by-jon-masters-of-red-hat/" target="_blank">video shows Red Hat's Jon Masters' explanation of AMD's Huskyboard</a>, where (even if only printed on cardboard) you can have a nice closeup view of the chip (video screenshot):<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAis96JeSuh_ScSWmLViEiaA7Ge_zpXO6U3Lxs7ynHPPn8FYTMBqH1ZeDSoAaVrmPnSjKD9e8SIzvM2cIRNZV0X4XMQ8TRF4RIWx8Wy_RKddgtD-pqLTYIzZrdsRnfdLXDSG9WzXNBOns/s1600/Seattle.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="AMD Seattle closeup" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAis96JeSuh_ScSWmLViEiaA7Ge_zpXO6U3Lxs7ynHPPn8FYTMBqH1ZeDSoAaVrmPnSjKD9e8SIzvM2cIRNZV0X4XMQ8TRF4RIWx8Wy_RKddgtD-pqLTYIzZrdsRnfdLXDSG9WzXNBOns/s1600/Seattle.jpg" title="" /></a></div>
<br />
The <a href="http://armdevices.net/2015/11/16/amd-huskyboard-96boards-enterprise-edition-softiron-overdrive-3000/" target="_blank">second video shows real hardware at work</a>, including SoftIron Overdrive 3000, and the Huskyboard in 3D:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBeDuf2OrlwNEJIrhn9c61tCq8ajpLY9PGfI_WrTddnoemhXuLwtZF-jYJdvJK-js0MTbpsPFkGQhwf29awOWM7pfMwLoRxp25vhrznOMJY0G7rL_V94N-SQCfubxOrKfarYq3bg2PDNA/s1600/Huskyboard+3.jpg" target="new"><img alt="AMD Huskyboard closeup" border="0" height="340" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBeDuf2OrlwNEJIrhn9c61tCq8ajpLY9PGfI_WrTddnoemhXuLwtZF-jYJdvJK-js0MTbpsPFkGQhwf29awOWM7pfMwLoRxp25vhrznOMJY0G7rL_V94N-SQCfubxOrKfarYq3bg2PDNA/s640/Huskyboard+3.jpg" title="" width="640" />
</a>
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJ1maEcYsmGruOkWKEq2dJ7ZcGuMNcI0wITVs3rZr0_r9cWMTr_c2U3UaQo3WpW-OJk_yHtSeaObCNy0b6L-39V9QldAttCd4tm7p_t4Y7hl6Tfvbh2MSXA5nm5E1oDw-de5mFUgocHio/s1600/SoftIron+Overdrive+3000+1.jpg" target="new">
<img alt="SoftIron Overdrive 3000" border="0" height="339" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJ1maEcYsmGruOkWKEq2dJ7ZcGuMNcI0wITVs3rZr0_r9cWMTr_c2U3UaQo3WpW-OJk_yHtSeaObCNy0b6L-39V9QldAttCd4tm7p_t4Y7hl6Tfvbh2MSXA5nm5E1oDw-de5mFUgocHio/s640/SoftIron+Overdrive+3000+1.jpg" title="" width="640" /></a></div>
<br />
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com3tag:blogger.com,1999:blog-3652428531631827883.post-17707754297149430272015-10-15T19:35:00.000+02:002015-10-16T00:26:23.549+02:00AMD Zen and K12 (ARM) tapeouts confirmed by LinkedIn profile<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: left;">
According to a LinkedIn profile, both Zen and K12 should have been taped out already. So this is a fact, as it isn't speculated based on sparse information. Interestingly the same guy (you have to find him yourself, if you need to), who only talks about CPU cores, mentions his working on 16nm and 14nm FinFet designs. So there will be one design made by TSMC and one by Globalfoundries. K12 by the first and Zen by the latter I suppose. And here is the snippet:</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBwVChTQHj2ENcGO53yHycDT6Z2jOttv_TAmooJG31S_5wdc1CyRpHIsG22RxhssdaSq6hBWDiTEV2v_gt28lCgWOfuohNA4axEitg5yy1ImV978YXLGxVJNzVUH_PchYfCrim95O5GRk/s1600/ZenK12_tapeout_snippet.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBwVChTQHj2ENcGO53yHycDT6Z2jOttv_TAmooJG31S_5wdc1CyRpHIsG22RxhssdaSq6hBWDiTEV2v_gt28lCgWOfuohNA4axEitg5yy1ImV978YXLGxVJNzVUH_PchYfCrim95O5GRk/s1600/ZenK12_tapeout_snippet.png" /></a></div>
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com4tag:blogger.com,1999:blog-3652428531631827883.post-88533005984028724392015-10-15T00:23:00.001+02:002015-10-15T00:23:49.138+02:00AMD's ARM-based "Hierofalcon" SoC sighted<span style="font-family: inherit;">On the same OSADL site, which once <a href="http://citavia.blog.de/2013/04/17/2-ghz-amd-jaguar-benchmarks-15761535/" target="_blank">provided some first signs of life</a> of a 2 GHz Jaguar based APU, there is now an engineering sample of one of AMD's ARM based embedded processors, called "Hierofalcon". The processor can be found in <a href="https://www.osadl.org/Profile-of-system-in-rack-a-slot-3.qa-profile-ras3.0.html" target="_blank">rack #a slot #3</a>. According to the tables and logs, it also runs at 2 GHz and has 8 cores. If you haven't heard of that processor, just check these two slides. I actually included the first only because of the bird. ;)</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhENf5oxbskWTKgsHzA5GfYHOHuCX6Ordnt_cmFuG0ASGTZ2E-77z62NTn2Sk6xMg7fS0asUIOa08EjpAHDMu7S7G3i_mzSxHQh-vCzOa8YqqwYsrxn05OGFUom5i7V4NXcoJjH4QUeFig/s1600/sourceimage.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="310" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhENf5oxbskWTKgsHzA5GfYHOHuCX6Ordnt_cmFuG0ASGTZ2E-77z62NTn2Sk6xMg7fS0asUIOa08EjpAHDMu7S7G3i_mzSxHQh-vCzOa8YqqwYsrxn05OGFUom5i7V4NXcoJjH4QUeFig/s640/sourceimage.jpg" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOLRHKpyYBydd-rtPiCHK9myNGKSXxVkZs7s2B07EcuhvTTvf_7UiowQzwQ99_UuTQVKxy6TEOpdD5yFwVxqXsda9M8xCxxi-cAG1I5kBSAVn0HNZb1J9V1QGZnv4DSfFubCSTzq-1At8/s1600/AMD-R-Series-Hierofalcon-SOC.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="356" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOLRHKpyYBydd-rtPiCHK9myNGKSXxVkZs7s2B07EcuhvTTvf_7UiowQzwQ99_UuTQVKxy6TEOpdD5yFwVxqXsda9M8xCxxi-cAG1I5kBSAVn0HNZb1J9V1QGZnv4DSfFubCSTzq-1At8/s640/AMD-R-Series-Hierofalcon-SOC.jpg" width="640" /></a></div>
<br />
I prepared some charts out of the numbers given there. If you check the site, you'll find no directly linked latency chart. But their <a href="https://www.osadl.org/?id=1337" target="_blank">1337 page</a> allows to compare rack #a slot #3 to some other rack/slot and returns the missed latency chart of the "Hierofalcon", which looks like this (updated daily):<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRRueoBK2nvHxW0WD4ZJ-DeytfZjIO7xkS1QqCcOZnjUtMRQF-QzgL9icUyLgpd9rofxZwQ4h9bKwb10_uNGnMokZtt0RJeXHqhHc4gI4XLP6IRsQAwp7WEyQmkhU-vqvxYsA1WvE_tp8/s1600/ras3.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Latency plot of AMD "Hierofalcon" ES" border="0" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRRueoBK2nvHxW0WD4ZJ-DeytfZjIO7xkS1QqCcOZnjUtMRQF-QzgL9icUyLgpd9rofxZwQ4h9bKwb10_uNGnMokZtt0RJeXHqhHc4gI4XLP6IRsQAwp7WEyQmkhU-vqvxYsA1WvE_tp8/s640/ras3.gif" title="" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Latency plot of AMD "Hierofalcon" ES</td></tr>
</tbody></table>
The only available performance numbers are some daily updated <a href="https://www.osadl.org/CPU-benchmarks.qa-farm-cpu-benchmarks.0.html" target="_blank">Unixbench results</a>. So I took them, combined rack names with CPU strings, sorted them, choose some CPUs for comparison, and normalized the results to the CPU in question.<div>
<br /><div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGZiPb8MKSaA3dNEWC1y4s2HDYeJZNxvhf2_JpxfxetKt2ZeBq5NTL8OhcmBOpI4Uv-lJPaOoBELQ645Ob-iqRkNc8WAilFiIHg2oSc1g2BGwzsurgQgdxjqhH6k3KcBFGK8RiNNM1wPA/s1600/chart_1c.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="433" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGZiPb8MKSaA3dNEWC1y4s2HDYeJZNxvhf2_JpxfxetKt2ZeBq5NTL8OhcmBOpI4Uv-lJPaOoBELQ645Ob-iqRkNc8WAilFiIHg2oSc1g2BGwzsurgQgdxjqhH6k3KcBFGK8RiNNM1wPA/s640/chart_1c.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The first chart already shows, that on a per clock basis AMD's other CPUs already lag behind in simple integer code of the old kDhrystone benchmark. The floating point based Whetstone benchmark draws a somewhat different picture with more equally distributed per clock performances except that of the old K10 based Phenom II. The next three benchmarks Execl (not Excel!), kCopy, and kPipe test OS functions like spawning processes, doing file copying or using the pipe. The Index is a combined result.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
In the next chart we can see the raw performance of all cores, only normalized again to Hierofalcon.</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTI9dGBe_srvjaPiaG3o98BDLDu2bk3TxT2m8fyYEjd2n8-k4qxs8ZcH1VFEaInRUpxpbwKHt2U9nsNHgYTrOJCwcEry0ju-peD13_GyD3H5RJgo5Gl5RKBVzZmfkQhyn998GTQSD_yxY/s1600/chart_ac.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="434" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTI9dGBe_srvjaPiaG3o98BDLDu2bk3TxT2m8fyYEjd2n8-k4qxs8ZcH1VFEaInRUpxpbwKHt2U9nsNHgYTrOJCwcEry0ju-peD13_GyD3H5RJgo5Gl5RKBVzZmfkQhyn998GTQSD_yxY/s640/chart_ac.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Even then the 8 cores of the ARM based processor have a good standing in the first two benchmarks, while in the OS benchmark, it roughly keeps up with Kaveri and Bulldozer, both running at much higher clock speeds.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The ARM based CPUs are meant to put many lower power cores together. To have a first impression of that effect, I used the given TDP numbers as the only metric available for all CPUs. Here are the power efficiency numbers:</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI6TKGMD0wepP16zon3hLm1v_RnrXdc8Y5m2Xbt9VvCOpb4iZwWN8kVOWd0rcYMXq4dMcZrqVAbjBXJaILFZ826K4mW9YrjvChSUVw48diYepVNf2YHCirfQ7YyZIZ7-8XJ7_q7wYWoUU/s1600/chart_pwr.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="434" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI6TKGMD0wepP16zon3hLm1v_RnrXdc8Y5m2Xbt9VvCOpb4iZwWN8kVOWd0rcYMXq4dMcZrqVAbjBXJaILFZ826K4mW9YrjvChSUVw48diYepVNf2YHCirfQ7YyZIZ7-8XJ7_q7wYWoUU/s640/chart_pwr.png" width="640" /></a></div>
<div>
<br /><div class="separator" style="clear: both; text-align: center;">
<br /></div>
I think in this case, the Hierofalcon bars are really easy to spot, even though I used the max listed TDP of 30W. Only the already power optimized Sandy Bridge variants and the 9W Kabini are able to keep up in some of the tests. And of course, real power measurements would shift the numbers a bit.<br />
<br />
Of course, many (including me) would like to see more interesting benchmarks, but these are the first numbers we've got and they aren't bad at all.<br />
<br /></div>
</div>
Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com5tag:blogger.com,1999:blog-3652428531631827883.post-2918831423333734772015-10-06T23:43:00.001+02:002015-10-06T23:43:21.106+02:00How Many Days Until Zen?Last weeks headlines went <a href="http://wccftech.com/globalfoundries-14nm-finfet-amd-zen-2016/" target="_blank">back and forth</a> about which foundry will be selected by AMD to produce wafers containing Zen based processors. After Jim Kellers departure, <a href="http://hexus.net/tech/news/cpu/86585-legendary-cpu-architect-jim-keller-leaves-amd/" target="_blank">Mark Papermaster assured</a> that Zen is on track for samples in 2016 and a full year of revenue in 2017. Before him pointing that out there was a comment on a LinkedIn profile, putting AMD's next gen x86 desktop processor straight into 2017.<br />
<br />So there are several data points of more or less official type. Let me add another one, which is based on the GCC patch publication pattern. This assumes, that there are work processes behind the patches and of course GCC related deadlines for inclusion of particular changes.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYhyPcR_Ne8jB0O8ympuaauPs-KKCSb4aECbaoeVd0Dq8xzC-LsjRMehCVdTzMnudO_lzKZs64xcDr9kVskj0PE-C1IKbhXGdrgjykKqqwKgwHyFEss-vYFz70S8CQy3pJhSBG8pbXVKY/s1600/Zen+Arrival.png" imageanchor="1"><img alt="Days between GCC compiler patches and CPU launch of Bulldozer and Cat core family CPUs with speculation of Zen launch." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYhyPcR_Ne8jB0O8ympuaauPs-KKCSb4aECbaoeVd0Dq8xzC-LsjRMehCVdTzMnudO_lzKZs64xcDr9kVskj0PE-C1IKbhXGdrgjykKqqwKgwHyFEss-vYFz70S8CQy3pJhSBG8pbXVKY/s1600/Zen+Arrival.png" title="Days between GCC compiler patches and CPU launch" /></a></div>
<br />
This chart shows the time delta in days between the publication of patches and the launch of a particular CPU containing a new core. For some launch dates only a month was given, so I took the last day of that month for the calculation.<br />
<br />
The Zen bars show the timeline in months starting with publication of the specific patch. With this at hand, anyone can draw their own conclusions. The scenario of first Zen based server or desktop CPUs hitting the markets in 4Q16 doesn't seem unlikely.<br />
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com0tag:blogger.com,1999:blog-3652428531631827883.post-22091456144324303752015-10-03T02:43:00.001+02:002015-10-03T12:26:46.222+02:00AMD's Zen core (family 17h) to have ten pipelines per coreWith writing about Zen I moved here since blog.de will close its service at the end of this year. That's it. Let's move on to the interesting stuff.<br />
<br />
Whoever has chosen the name "Zen" for AMD's next generation x86 core, might have had the number four in mind, which plays an important role in this philosophy (e.g. <a href="https://en.wikipedia.org/wiki/Four_Dharmadh%C4%81tu">Four Dharmadhātu</a>). At least this is what a recent <a href="https://patchwork.ozlabs.org/patch/524324/">patch</a> revealed about this long awaited microarchitecture.<br />
<br />
Andreas Stiller <a href="https://translate.google.de/translate?sl=de&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http://www.heise.de/ct/ausgabe/2015-22-Prozessorgefluester-Von-Schummeleien-bei-Autos-Benchmarks-und-Bilanzen-2828004.html&edit-text=">speculates</a> that the term Zen as in "SuZen" might be related to Zen team leader Suzanne Plummer and possibly Lisa Su as well. An article on <a href="http://www.mystatesman.com/news/business/amid-challenges-chipmnaker-amd-sees-a-way-forward/nngdf/">myStatesman</a>, which appeared shortly after Jim Keller's leave, lists some more team member names if you magnify the photo:<br />
<br />
<blockquote class="tr_bq">
<i><span class="related-photo-caption">Mike Clark, front left, and team
leader Suzanne Plummer, and in background from left are Teja Singh,
Lyndal Curry, Mike Tuuk, Farhan Rahman, Andy Halliday, Matt Crum, Mike
Bates and Joshua Bell.</span></i></blockquote>
<br />
Mike Clark is a true AMD veteran, being there since 1993. Some have developed the Cat cores, like Teja Singh and Joshua Bell, who presented the <a href="http://www.hardware.fr/marc/ISSCC2013-Final-v5.pdf">Jaguar microarchitecture</a> at ISSCC 2013. <br />
<br />
As <a href="http://techreport.com/review/28228/amd-zen-chips-headed-to-desktops-servers-in-2016">heard earlier</a> this year, Zen will use SMT and an improved cache subsystem while being designed from scratch with new ideas combined with reusing existing components (to reduce the effort). This might even include already existing and somewhat developed ideas not realized in previous designs. A lot of the new functionality has been filed for patenting. For example there was a mention of checkpointing, which is good for quick reversion of mispredicted branches and other reasons for restarting the pipelines. Some patents suggest, that Zen might use some slightly modified Excavator branch prediction.<br />
<br />
And the new patch also suggests nicely low int/fp mul, fp add, int/fp div and fp square root latencies. Some of these lower latencies (div/sqrt) were introduced with Excavator, as an <a href="http://pastebin.com/7A7Chkiu">Aida64 instruction latency dump</a> provided by Anandtech forum user <a href="http://forums.anandtech.com/showpost.php?p=37740183&postcount=2551">monstercameron</a> revealed. Due to an Aida problem with measured and reported clock frequencies (although it was fixed at 1.4GHz), you have to multiply the measured times by 1.4 to get the real number of cycles. Ok, back to Zen.<br />
<br />
Here are some quotes of the patch file:<br />
<br />
<blockquote class="tr_bq">
<pre class="content"><span class="p_add">+;; Decoders unit has 4 decoders and all of them can decode fast path
</span><span class="p_add">+;; and vector type instructions.</span></pre>
</blockquote>
<blockquote class="tr_bq">
<pre class="content"><span class="p_add">+;; Integer unit 4 ALU pipes.</span></pre>
</blockquote>
<blockquote class="tr_bq">
<pre class="content"><span class="p_add">+;; 2 AGU pipes.</span></pre>
</blockquote>
<blockquote class="tr_bq">
<pre class="content"><span class="p_add">+;; Floating point unit 4 FP pipes.</span></pre>
</blockquote>
<blockquote class="tr_bq">
<pre class="content"><span class="p_add">+ 32, /* size of l1 cache. */
</span><span class="p_add">+ 512, /* size of l2 cache. */</span></pre>
</blockquote>
<br />
Excerpt:<br />
<ul>
<li>4 wide decoders</li>
<li>4 integer ALUs</li>
<li>2 AGUs (for 2R 1W L1 cache according to a LinkedIn profile)</li>
<li>4 FP pipelines</li>
</ul>
That makes <strike>z</strike> ten pipelines with a general four wide design.<br />
<br />
There is a lot more information, which I will collect over the next days. Some stuff is copy pasted from Excavator (bdver4) or Jaguar (btver2) and modified then. But careful comparing did show some clear differences, while at other places it's not clear, if there is new information or not (e.g. div latencies). But as btver2 has 2048 kB L2 and the rest of the block is more similar to bdver4 or btver2 than btver1 (Bobcat), which has 512 kb L2, it looks like no btver1 files were used as a source. So I assume, that this is a new entry of an L2 cache size, indicating fast L2 caches per core. The L1 data cache still has the same size as that of Jaguar or Excavator. Some patents mention an 8-way 32kb L1 D$.<br />
<br />
Interestingly, as there are two 128b FP mul and two 128b FP add units (with only 3 cycles latency for these ops), the FMA instructions will be executed by combining one FP MUL and one FP ADD unit, resulting in 2 issues and 5 cycles latency (as that of the Bulldozer family). This saves some register file ports and increases throughput and reduces latencies of the more common FP ops. It even remembers me of the <a href="http://citavia.blog.de/2009/11/23/some-additional-bits-of-information-7441398/">bridged FMA unit</a>.<br />
<br />
These latencies also clearly suggest, that this is no high clock frequency design. But at 14nm (or 16nm from TSMC as some rumours suggest) clocks of 3.5 to 4 GHz should be reachable without stretching the thermal limits too much.<br />
<br />
This should be enough for now. Here is a schematic, which should come close to what Zen might really look like:<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8Y63o82fOF7gWjXwqL0mnKvA8njv1ollEfDlCmoS8TRx7Y3zMtVyZdrK-eB5unnFOgRKZYsPwn8eEshxz0uHnsFE0EG64mWxt-q2Fh7bcc1iZ0lU27VtEfXXTASEQanuSX4VaGaUW8K4/s1600/Zen-Architektur+Core+V0.2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="AMD Zen Core Microarchitecture" border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8Y63o82fOF7gWjXwqL0mnKvA8njv1ollEfDlCmoS8TRx7Y3zMtVyZdrK-eB5unnFOgRKZYsPwn8eEshxz0uHnsFE0EG64mWxt-q2Fh7bcc1iZ0lU27VtEfXXTASEQanuSX4VaGaUW8K4/s640/Zen-Architektur+Core+V0.2.png" title="AMD Zen Core Microarchitecture" width="588" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">AMD Zen Core Microarchitecture (with some speculated parts)</td></tr>
</tbody></table>
<br />Dresdenboyhttp://www.blogger.com/profile/15574049389666017448noreply@blogger.com15