This is a bit unusual. I got an email from AMD PR this week asking me to correct the Bulldozer transistor count in our Sandy  Bridge E review. The incorrect number, provided to me (and other reviewers) by AMD PR around 3 months ago was 2 billion transistors. The actual transistor count for Bulldozer is apparently 1.2 billion transistors. I don't have an explanation as to why the original number was wrong, just that the new number has been triple checked by my contact and is indeed right. The total die area for a 4-module/8-core Bulldozer remains correct at 315mm2.

CPU Specification Comparison
CPU Manufacturing Process Cores Transistor Count Die Size
AMD Bulldozer 8C 32nm 8 1.2B ~2B 315mm2
AMD Thuban 6C 45nm 6 904M 346mm2
AMD Deneb 4C 45nm 4 758M 258mm2
Intel Gulftown 6C 32nm 6 1.17B 240mm2
Intel Sandy Bridge E (6C) 32nm 6 2.27B 435mm2
Intel Nehalem/Bloomfield 4C 45nm 4 731M 263mm2
Intel Sandy Bridge 4C 32nm 4 995M 216mm2
Intel Lynnfield 4C 45nm 4 774M 296mm2
Intel Clarkdale 2C 32nm 2 384M 81mm2
Intel Sandy Bridge 2C (GT1) 32nm 2 504M 131mm2
Intel Sandy Bridge 2C (GT2) 32nm 2 624M 149mm2

Despite the downward revision in Bulldozer's transistor count by 800M, AMD's first high-end 32nm processor still  boasts a higher transistor density than any of its 45nm predecessors (as you'd expect):

Transistor Density Comparison

Transistor density depends on more than just process technology. The design of the chip itself including details like the balance between logic, cache and IO transistors can have a major impact on how compact the die ends up being. Higher transistor densities are generally more desirable to a manufacturer (fewer defects per die, more die per wafer, lower costs), but from the end user's perspective the overall price/performance (and power?) ratio is what ultimately matters.

Comments Locked


View All Comments

  • Khato - Friday, December 2, 2011 - link

    Do we have any reason to trust the AMD PR department right now? Because what it sounds like to me is that 1.2B may be the functional design transistor count, and 2B may be the actual floorplan transistor count with a nice huge 800M discrepancy because of their lackluster physical design. I mean, those huge 'dead' spaces between the actual logic blocks in the die shot (you can distinctly see each module, L3 cache, and uncore) are almost certainly automated signal routing, and with those kinds of distances it's guaranteed that you're going to have a lot of repeaters...

    I can easily see AMD PR deciding that it looks bad to be using so many transistors to get such pathetic performance... so why not claim the other transistor number? There's no real way to confirm or deny their number. And they can justify it with the pathetic excuse that they're only using 1.2B transistors on the actual design, even if actual silicon has far, far more.
  • Phylyp - Friday, December 2, 2011 - link

    I now have a question - how do they come up with these numbers? Is it an estimate? Is it a true count at the tape-out point?

    If its an estimate, I can understand how a changed/improved estimation technique can revise the numbers... though a 40% variation is extremely shoddy.
  • MS - Friday, December 2, 2011 - link

    At 16 MB total L2+L3 cache, the transistor count for those two caches alone comes out as 1.2 B transistors
  • Khato - Friday, December 2, 2011 - link

    Indeed. Though the linked post is slightly off as its calculation equates 16M to 16e6 instead of 16*2^20. Using the correct equation results in 1207959552 transistors...

    So apparently AMD's PR department can count L2+L3 cache transistor numbers?
  • MS - Friday, December 2, 2011 - link

    That's correct but for the proof of the concept I thought I use the simplified decimal metrics instead of the binary equation. Otherwise, who knows what kind of algebraic abuses I would see in the replies.
  • Khato - Friday, December 2, 2011 - link

    Haha, fair enough. Either way, the end result is quite amusing.
  • Khato - Friday, December 2, 2011 - link

    And now to reply to myself as I wake up a bit more...

    The number is more likely around 900M for the L2+L3 cache as they appear to be using 6T sram as usual there. Still, the point stands that the 2B transistor number seems about right.
  • MS - Friday, December 2, 2011 - link

    Yes, I updated my post accordingly as well.
  • Chaki Shante - Friday, December 2, 2011 - link

    Correct me if I'm wrong, but I thought that transistor count was never an exact figure. Designers usually get a NAND equivalent gate count, from their design tools, as if all gates were the same type so this is a first approximation. Then transistor count is derived by simply multiplying by a factor of 4, the number of transistors in one Nand gate. Can it explain the discrepancy?
  • MS - Friday, December 2, 2011 - link

    Yes, it could, at least to a certain degree. Specifically, if AMD applies the "logic transistor" footprint to the overall used die size, i.e. the parts that really have some functional transistors as opposed to some areas that are interspersed as fillers - physical connections (which there are plenty of on BD). This might give you one number for the transistor count.

    Now, as mentioned in various locations, cache / SRAM transistor footprint is substantially smaller than logic or, to put it differently, the packing is much denser. So if you applied logic transistor density to cache area, you get a pretty wrong number - it will depend, among other things also on the specific SRAM cell and so on.

    So yes, in general you are correct and I have a hunch that the 2 B vs. 1.2 B would come out quite well if you just do that type of "Stupid math" without differentiating between die areas. In that case, both numbers would be wrong and the real transistor count would probably be more in the area of 1.75-1.8 B transistors total.

    I have left messages with AMD but received not a single word of feedback.

Log in

Don't have an account? Sign up now