AMD Bulldozer Core Patent Diagrams

Discussion in 'PC Industry' started by Raqia, Apr 16, 2009.

Tags:
  1. Raqia

    Regular

    Joined:
    Oct 31, 2003
    Messages:
    508
    Likes Received:
    18
    That does seem like a major stumbling block. One of the slides for SR mentioned that store forwarding was improved so this might be more balanced now.
     
  2. itsmydamnation

    Veteran Regular

    Joined:
    Apr 29, 2007
    Messages:
    1,330
    Likes Received:
    444
    Location:
    Australia
    people seem to think the wcc between the L1 and L2 can cause problems as well.

    http://www.agner.org/optimize/blog/read.php?i=225

    seems to be some massive performance cliffs if you cause the wcc to overflow.


    fellix aida 3 crashes in my vmware guests :cry:
     
  3. mczak

    Veteran

    Joined:
    Oct 24, 2002
    Messages:
    3,020
    Likes Received:
    115
    That's just a result of the L1 writethrough cache. So a L1 write is always writing to L2 too (the number is higher than L2 write presumably because a L2 write would also include a L2->L1 read). And yes this appears to be a weak point, though it's unclear how much this contributes to general lackluster performance of BD. I don't know if SR changes any of this as this was probably chosen for a reason, but one "easy" "fix" would be doubling L2 throughput.
     
  4. 3dilettante

    Legend Alpha

    Joined:
    Sep 15, 2003
    Messages:
    8,555
    Likes Received:
    4,725
    Location:
    Well within 3d
    The watch.impress segment has some interesting breakdowns of the chip.
    Notably, the amount of HVT transistors drops massively from 32nm to 28nm.

    The overall shift to having more nominal Vt transistors and a larger proportion being regular-length seems to match up with the general premise that Steamroller's top end is somewhat lower, so more can be put in the nominal pool than before.
    However, the drop in HVT was such that I wonder if it had to do with some quirk like dropping SOI.
    The leakage numbers show a generally more leakage-resistant process, except for again the fastest and leakiest transistors.


    Electronics Weekly had one sentence mentioning resonant clocking, but is it any more so than the non-appearance for Piledriver?

    Another blurb is the mention of the vdroop-detecting clocking scheme.
    These days, these dynamic schemes echo for Intel's Foxton technology more than ever.
    Intel has a vdroop-aware clock scheme for its experimental graphics core.
    AMD seems to be using it to keep things functional at regular voltages, while Intel's for near-threshold.

    edit:

    One thing I forgot to comment on was the number of custom macros for Steamroller.
    It has an order of magnitude more than AMD's Jaguar.
    Part of that may go to the requirements for Steamroller's per-core performance range, as well as the historical tie that architectural line has with the old AMD fabs.
    I would wonder if a Bulldozer-derived core would ever be found on a non-GF process with that level of specificity (and since Jaguar with much less hasn't been hopping fabs), and whether that could have been what scared Sony away from the rumored Steamroller PS4.
     
  5. Raqia

    Regular

    Joined:
    Oct 31, 2003
    Messages:
    508
    Likes Received:
    18
    There's a tweet about Steamroller's use of macros:

    https://twitter.com/MikeDemler/statuses/433020331532378112

    "#ISSCC Design complexity drove more use of automation in AMD Steamroller. Replaced multi-day SPICE pwr analysis with SNPS DOE tool, SP&R."

    No idea what some of those acronyms mean. Hopefully, a full slide deck or a taped presentation like the one for bobcat crops up.
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...