Friday, September 08, 2006

The Coin has three Sides

NOTE TO THE AUDIENCE: My apologies to the audience. I took a long time before siting and doing this one. Actually, I am sacrificing a free Friday to do it, but i figured out that I either do it now or never. Besides, a promise is a promise..... So here it is!

WARNING: LOOOOONG POST!

When I say it, it is obvious. I can hear the audience saying: "¡Well yes, of course, the coin has three sides! Head, tail, and the ..." and there the English speakers stop. They do not even have a name for it. The best they can come up with is "the edge" (I consulted with some native English speakers in my MBA program, from Britain AND the US). In Spanish, at least, we use the word "canto (de la moneda)" for that third side. You see, is rather obvious, but people tend to ignore it. Everybody talks about the other side of the coin, and all people think about the coin is flipping it. One day, I flipped a coin, and it landed on the canto, rolled to a small crevice, ¡and stood on its canto! (I was an undergrade at the time). Yes, the coin has three sides.

Imagine that I show you pictures of €1 and €2 coins, modified so that sizes and colors are the same, and ask you questions about the coin, depending on the question, you will be able to use one or mode of the sides to know the answer, for instance:

¿In which country the coin was minted? You will need the decorative side.
¿How much is it worth? You will need to look at the value side (the value is printed there), or to the "canto" (€1 is alternating stripes and smooth, €2 is all stripes).
¿Is it a collectors edition? Again, look at the decorative side.

But read again the conditions: «modified so that sizes and colors are the same». So, there are other aspects of coins, like color, size, material, or even weight, that are important when analyzing the coin.
Translate this to the blogsphere: many times, you see unidimensional analysis. I takes into account, one, perhaps two, exceptionally three, aspects of the coin. More often than not, the people restrict themselves to performance, and technical merits, and forget about other aspects, financial, marketing, or my favorite, strategy (we will talk A LOT more about strategy in future posts).

Before we begin, CORE2 is here, the benchmarks are here, and the thing is good. Or at least good enough. So, it seems easy for me to say this things now, but Chi is my witness, this is the same I was telling him in January 2006.

Let's revisit some popular and not so popular issues of the AMD vs. Intel debate, looking at some other aspects, strategic aspects. The idea here is that you see that there is more to the debate, and try to open your mind, and perhaps find other aspects for yourself (for instance, if you are a finances guy, we could use some insight there, get the sec reports and get to work!).

INTEGRATED MEMORY CONTROLLER: Lets get this out of the way: from a technical and performance point of view, having an IMC is better than using FSBs and NorthBridges. There, I said it, there is no denying of the truth, but there are other aspects to the coin than performance and technical merit ¿right? (think about it for a minute or two before continuing, you have read a lot already, you deserve a little break).


In the late 1990's, Intel was using RAMBUS RD-RAM all across the board, and working on a µProcessor codenamed Timna with an IMC. The idea here was not to get more performance, but to lower the cost, but that was the perfect opportunity to taste for real the benefits of an IMC. Intel figured that by the time Timna came out, the cost of RDRAM would be much lower. But, lo and behold, because of the "Cloak and Dagger" dynamics of the RAM market at the time (RAMBUS misappropriated patents, while the DDR manufacturers used predatory prices on RAMBUS, do not take my word, google for it; ArsTechnica, as usual, has a good summary on the issue) Timna ended up being a very inexpensive chip, tied up with a awfully expensive memory subsystem, and the chip was scraped. Ever since, Intel has been shy of tying the µProcessor to the Memory Architecture. AMD did, and by doing that (and getting a little lucky with the memory choice) reaped a huge payoff.

But now, AMD is at crossroads, while Intel is, believe it or not, in a better strategical position. As of now, AMD has to watch out for FOUR (4) Memory technologies. DDR1 in the value market, DDR2 in Mainstream and server markets, and the future FB-DIMM and DDR3 in the server space.

If you take any Supply Chain Management 101 book, they will tell you that the more you delay customization, the more efficient your production process becomes. As of today, when AMD has to tailor the memory the customer wants, they have to do it right in the very minute when the masks are put in the FAB. Intel tailors the memory when the chip is dropped in the motherboard. Who do you think has the most efficient supply chain, the less problems doing forecasting (think µprocessors only, not chipsets, at least, not for now), and can take out products faster to market? When Hector Ruiz tells you that they will introduce new memory technology when "it makes sense" he is telling you the truth, but not the whole truth. AMD introduces new memory technologies when it makes sense to the market AND TO AMD. And, to top it of, if this time around AMD picks the wrong technology (they are backing DDR3 instead of FB-DIMM) there will be hell to pay!

Have you heard that upcoming AM3 processors will fit in AM2 boards, and will support both DDR2 and DDR3 memory (but not in the same board). That is AMD trying to get out of this bad strategy position. Right now, some clever engineers at Intel are trying to get CSI done, and I guess that a lot of their thoughts are on ¿How much of the memory controller can we put inside the µProcessor AND STILL remain Memory Architecture Independent?

MULTICORES: Up until now, whenever we move to a higher number of cores (one to two, two to four), Intel puts two slabs of silicon in the same package, and only later comes with a real multicore, while AMD comes out with real multicores from day one. Again: from a technical and performance angle, having a real multicore is better than having two slabs of silicon. But, as usual ¿are there other angles to the issue? (¡WOW! ¿You are still here? Think about it while you fetch a snack, a glass of water or a take a pee break, before continuing).

Nowadays, Software licenses for big apps are paid per socket, not per core. That includes things like DB2, MS-SQL (Oracle uses a very weird pricing scheme, and world + dog is complaining about it), HP-UX, ExchangeServer, or SAP (some of those have (F)OSS alternatives, other do not). That means that, as long as one does not use more sockets, no matter how is done, is better, because a µProcessor price is in the range of a $1000,oo range, while a SW licenses is in the many tens of thousands of Dollars PER SOCKET.

So, for example, if one is running a one socket Intel server with a single core proc, and needs more processing power (electricity and cooling aside; sometimes those are important, sometimes they are not; in many large organizations, the budget for air conditioning and electricity does not come out from the IT people, so, as long as this is not the server that breaks the camel's back, the IT people have not much incentives in taking that into account), one can:

* Get an Intel Crippled Dual Core now and get a 1.7 performance boost on the same server, and replace that with an Intel RealDualCore latter on, getting in the end a 2.2 performance boost over the initial configuration for a couple of grand.
* Do a forklift upgrade to a dual socket AMD config now for around 10 grand + SW certification costs (you are changing the configuration), with a 2.6 performance boost and DOUBLE the SW price.
* Wait a few months (if you can, and you not always can) do a forklift upgrade to a single socket AMD with 2.5 performance boost over the old configuration for around 10 grand + SW certification costs.

Of course, you can construct an scenario where is better to use AMD, but AMD has been 0 to 26% of the server market, so I guess that case is more frequent than the alternatives. The same case can be extrapolated to dual or quad socket machines, or machines with free sockets. But the important thing with the example is to force you to think and grasp another side of the coin.

If one is in the market for QuadCore servers is not because QuadCores are cool, or perform better, but because one wants A GIVEN LEVEL OF PERFORMANCE WITH MINIMUM SW COST. The first one to market with QuadCores, is the one which will give us that. And, lo and behold, even Crippled, the first ones to market with that are the guys from Intel.

There is another issue. Every time one gets to a new increase in performance, the market for it is the upper tail of the bell curve. Intel slaps together two cores, not much R&D expenses there, and satisfies (more or less) that market. When that market becomes more mainstream, Intel invests the resources in making it right (finances 101, Time Value of Money, delayed investments are better). AMD, on the other hand, has to make the sizable investment in designing "yet another set of masks" right here right now.

Finally, we run again into the Supply chain 101 issue. The more you delay customization, the more efficient you are. At least in the beginning, Intel delays customization (¿two cores or four?) up until the testing and packaging steps of the fabrication process, while AMD does it right when the µProcessor is made. If there is an error in demand forecasts, ¿who will get in trouble (obviating for a second packaging issues, like the one AMD faced in December 2005 ;-))?. And no, APM will not save AMD from bad forecasting.

Of course, ¡AMD is not stupid! ¿Why don't they do the same and pack two slabs of silicon in the same package and call it a Quadcore? Aside from Hector Ruiz's reasons (which are true, but not the whole truth) I can think of two reasons (sure the audience can think of more):

* AMD lacks the expertise. Putting to slabs of silicon in the same package is easier said than done. Intel has been doing it since the PentiumPro, and probably, to get to the point of being confortable doing it with a mass market part, they were doing R&D on the subject long before that. By the way, since this is the second time I mention R&D, head to the IEEE Spectrum website and see the survey of R&D expenditures for 2005 (Jan. 2006 issue). See where is Intel and where is AMD.

* If you put two AMD dual cores in the same package, each dual core will have its own memory controller, but the pinout should be the same as that of the DualCore parts (otherwise, you loose the drop in replacement market). Therefore, one of the DualCores (lets call it A) will talk to memory directly, while the other one (B) will, essentially, have an external memory controller (the IMC of B will talk to the IMC of A which will, in turn talk to the memory; if that is not an external memory controller, tell me what it is). Therefore, for two of your four cores, the IMC advantage is gone, without the corresponding increase in bandwidth (pin compatible, remember). Evidently, since their design is inferior, for Intel this is not an issue ;-)


MICROCODE UPDATES: (Thanks for getting here. I saved the best for last. This is the last one).

Engineers are humans, and humans make mistakes. In the mid 1990's Intel made two mistakes with the original Pentium. The FDIV bug, and the F0:0F bug. Intel learned their lesson, and, ever since the PentiumPro, they have something called Microcode Update. Basically, is a way to patch the microprocessor on the fly to correct errors. You can put it in your machines BIOS, or you can run a piece of SW to do it for you. But you have to do it each time you boot your machine. The point is, you patch in just one point, not in every single OS AND/OR Application known to man.

Some ten years latter the innovative and technologically leading AMD has nothing similar. And yes, AMD chips have bugs too (google for them). OK, so far so good, is easier for Intel to patch the chips that it is for AMD. Are there other implications. This is my post, so you bet there are!!!

What this means is that AMD has to take longer to weed errors out of their chips (because having severe errors for them implies costly patches in many applications, or even worse, a recall), while Intel can go a tad faster. So, when Mr. Otellini enter the design room and says "we are moving forward the launch of the CORE2" the engineers grumble and move on, but if Mr. Ruiz ever tell his engineers they need to move a launch forward, there will be a riot!

I remember, in the month preceding the launch of CORE2, having a grin whenever Chicagrafo and Sharikou denounced that CORE2 would be unstable and buggy. I thought: "¡Well of course it will be unstable and buggy! The question is ¿for how long?. How could Chicagrafo and our respected Ph.D. overlook the Microcode update feature is beyond me....

This feature is part of the reason why Intel could pledge to roll a new architecture every two years, and AMD can not match those stakes. And that (architecture every two years) issue will be discussed in more depth in a future (shorter) post.



Thanks for bearing with me. I wait now for your comments... Contrarian comments are welcome, but lets keep the thing on a high level, no flames!

15 comments:

Anonymous said...

I always appreciate a detailed discussion on the technical merits. It provides opportunity for something more than substance-less flame-wars and personal assertions.

So thank you... but I'm not finding myself in agreement with all of yoru conclusions.

With respect to your microcode arguments...

It seems to me that microcode updates are only useful for resolving certain kinds of bugs. As a reference for my assumption, I present the following (from the recently popularized core2 errata document):

http://download.intel.com/design/processor/specupdt/31327902.pdf

(sorry for not making it a real link--tinyurl below):

http://tinyurl.com/lo3fs

From page 7...

"Intel intends to fix some of the errata in a future stepping of the component, and to
account for the other outstanding issues through documentation or Specification
Changes as noted."

Seems to me like the document is saying that the fix will require a new stepping of the processor (new processor chip) rather than a simple software update. Sure, fixes can be applied by software workarounds, but that's the very same boat that AMD is in, according to your arguments.

Could you elucidate on this topic?

Eddie said...

<<
(for instance, if you are a finances guy, we could use some insight there, get the sec reports and get to work!)
>>

Howling, in the message board there are all kinds of skills and talents represented in the many good regulars. This blog is less dimensional than what you would like because I am stronger in the technology and can best use my efforts focusing on my greatest strengths. But there are multiple MB analysts who read all the filings of AMD and other companies too, to put things into perspective. Thanks to Sharikou, for instance, I learned that Dell has a huge market cap to book value multiplier, whereas Sun has a small one, and there are former portfolio managers, and all in the MB. Use this wonderful link to get there, to "our" MB: http://tinyurl.com/pg8um

<<
Intel figured that by the time Timna came out, the cost of RDRAM would be much lower
>>

I don't think so. I think that Intel, in its supine arrogance, just assumed that since they had committed the Pentium 4 to Rambus it will become cheap. And I might add, the push for Rambus was precisely to de-commoditize the market just likew they tried with the Itanium with identical success. On the other hand, AMD insisted in an evolutionary and open approach, producing DDR and AMD64 that eventually crushed Intel's world domination plans. An appropriate link.

<<
But now, AMD is at crossroads, while Intel is, believe it or not, in a better strategical position. As of now, AMD has to watch out for FOUR (4) Memory technologies. DDR1 in the value market, DDR2 in Mainstream and server markets, and the future FB-DIMM and DDR3 in the server space.
>>

Oh, no! heresy! ;-)

The strategic advantage of having the option to handle any kind of memory is peanuts compared with the horrendous scalability defficiencies of Intel processors, therefore Intel is in the sink hole.

<<
And, to top it of, if this time around AMD picks the wrong technology (they are backing DDR3 instead of FB-DIMM) there will be hell to pay!
>>

Why would AMD make the wrong pick? As I told you before, AMD knows what it is doing. You now see Intel backpedalling on FB-DIMMS because they are far too power hungry (this link comes from the MB, forgot who posted it originally). Why am I confident on that AMD will keep doing the right choices?: Because it is not something that requires so much sophistication but common sense. By the time the market is ready for AMD supporting a type of memory that type of memory should be very consolidated and the choice would be obvious. Intel, on the other hand, is all circus, show, and marketing gimmicks.

<<
¿How much of the memory controller can we put inside the µProcessor AND STILL remain Memory Architecture Independent?
>>

That's nonsense. You either speak to memory directly or not. If you do, then you have to implement the protocol on chip and to couple the whole design to the memory architecture intended to be supported. If you don't speak directly to memory then you have an intermediary and the intermediary screws the chance to have P2P interprocessor communications, cache coherency, non memory uniform architectures (NUMA), and you have to pay a latency penalty.

That is not all, AMD is very determined to focus on modular chip µarchitectures (this is also justification for the ATI purchase) thus, whether to put a DDR2, Z-RAM, DDR3, FB-DIMM, whatever, will eventually be trivial for AMD.

<<
Nowadays, Software licenses for big apps are paid per socket, not per core
>>

That's true, but interestingly enough, VMWare defines a processor as "a single, physical chip that houses no more than two (2) processor cores"

Now, it is commendable of your article that it is the first real justification I have seen for Intel kludgecores.

But, pardon my ignorance, isn't it also expensive to "discreticize" single dice into MCMs?

About Microcode Updates, it is rumored that AMD has some sort of the same thing. It is reasonable to expect that modern µprocessors, which are probably the most complex devices ever designed, have multiple fault tolerance mechanisms, including means to reprogram the microcode.

About Intel's Core errata, there are so many scenarios and pair interactions, and even triplet interactions to consider that it is impossible to test a µprocessor in most border cases; therefore only with widespread usage the bugs show up, when the processors are already in the market. I saw the list the anonymous poster points out, but I didn't see any show stopper.

That it is required an stepping update is not very meaningful, especially taking into account the very limited quantities of CMW that are in the wild.

Anonymous said...

"That it is required an stepping update is not very meaningful, especially taking into account the very limited quantities of CMW that are in the wild."

Eddie, you acknowledge my point, but not directly. The point is, a stepping update is required.

Regardless of the current quantities in the wild, it appears that the bugs listed in the errata document may not be fixed by some kind of microcode update. Indeed, the document implies that the options are:

1). Software developers need to implement workarounds

2). Server owners will need to insert new processors on newer steppings (where the bugs have, presumably, been fixed), in order to "fix" the bug.

If Intel had sold 50 million Core2 CPUs and then discovered the bugs listed in the errata, it seems that microcode would not have helped them to fix those bugs.

And if one of those bugs had been an extremely critical one (with 50 million CPUs in the field), what benefit would microcode features bring?

The errata document implies that they (microcode features) might not be capable of fixing the bug at all.

Thus, I offer the notion that microcode features are not the strategic coup that Howling suggests they are... or at best, they are a coup in limited circumstances.

Am I wrong?

Eddie said...

You have seen the errata, you should now that the mistakes there are a matter of fringe cases that very seldomly, if at all, happen in day to day computing. These are not FIDIV bugs.

That Intel declares that it doesn't know of a fix doesn't mean that the processor is "spoiled goods", just that either the O.S. and applications have to implement a workaround, or to avoid using the faulty feature. This last case may lead to nasty application incompatibilities, but again, the errors detected are no show-stoppers.

If I were a µprocessor designer, I would make sure that a feature like the microcode updates would work for the important, very popular instructions and abandon the very infrequent and very OS dependent instructions on their own.

There is no significance that the microcode updates have limitations and that it can not correct any error; so far, my first check of the list doesn't show any compelling reason to worry about the bugs in the current steppings.

The critical importance of the microcode updates is that it allows to quickly develop new architectures, an issue which is extremely important.

Anonymous said...

Eddie, I must disagree on the merits of the bugs noted in the Core2 errata versus the FDIV bug.

There are some who would argue that FDIV ended up causing a significant public outcry, but did not cause a significant amount of data corruption, etc.

I don't see a lot of difference between FDIV and the Core2 errata (or, for that matter, AMD's recent issue as noted here:

http://www.amd.com/us-en/0,,3715_13965,00.html?redir=CORPR01)

Again, my point being that I don't see Intel as having a significant advantage with a microcode feature (in contrast to Howling's original post).

Whether it's because microcode has limitations to flaws it can address, or whether or not those flaws are "extremely fringe" ... the end conclusion should be the same.

So, Eddie, I agree with the point of your argument, but not the technical specifics of it.

(Side note, it's interesting that this discussion seems to have so much less traffic than the near daily bombs that Sharikou drops... perhaps this blog needs to find a way to increase its entertainment factor... :-D ).

Intel will BK in 5-7 quarters!!!

There... that ought to attract a crowd. ;)

howling2929 said...

Thank you anonymous and Eddie.

*** First, to the Microcode Update. Yes, is true that there may be problems that can not be resolved by a microcode Update, but the fact that the document says "Future stepping of the component" does not mean necesarily ´new silicon´. Each time you apply a microcode update to an Intel Microprocessor, the stepping number of the processor is changed. Try it yourself, if you still have a PIII around there, or google for the behaviour of the Microcode Update application. Or grab your most recent copy of Scott Mueller´s "Upgrading and repairing PCs" (highly recomended book) and check on the tool.

While we are at it, and for full disclosure, with Microcode Updates there is a posibility that the fix makes the processor slower, but in the 10 years of existance of the tool, that has never happened.

Finaly, as eddie pointed out, the real issue i wanted to take is the strategic position that having the tool brings, versus not having it.

*** On the memory controller: Eddie said "That's nonsense. You either speak to memory directly or not." That is not necesarily true. One can perfectly put enough of the memory controller inside the microprocessor to reap the NUMA, interprocessor communications, virtualization and cache coherency benefits, and leave enogh outside (for instance, using a mezzanine bus) to remain memory architecture independant, and pay the price of higher latency cost for that independence. In the end, engineering is all about tradeoffs.

*** On the SW prices: Yes, VMWare is free to set a price like the one you describe, and oracle has (as i said) an even weirder pricing scheme (for X86 your price is Baseprice*[#ofSockets+0.25*#ofCores]) but most analysts think that in the end everyone will converge to charge per socket only.

*** CludgeCores: Of course the packaging process is more expensive, And I do not know how much of a percent, but for a market where volumes are low, and profits are high (server) the difference is peanuts compared to designing a whole new mask, including redesigning the memory controller to join 4 cores, and almost doubling the size of the chip (compared to a dual core) slashing the yields by half.

Eddie said...

<<
(Side note, it's interesting that this discussion seems to have so much less traffic than the near daily bombs that Sharikou drops... perhaps this blog needs to find a way to increase its entertainment factor... :-D ).
>>

Thank God! I simply wouldn't be able to handle the traffic that Syndrome "handles".

This space is different, I don't post because I may have a weak ego nor I need to convince myself that I am smarter nor better informed. This is a place to bring ideas, not shows of bullshit. Syndrome's blog is totally different, primordially it is a show with a collection of exagerations and intellectually dishonest links and analysis; without real audience participation. Go there and post a message that Syndrome can not easily dismiss and you'll see that it doesn't even get published.

On the other hand, my posts have book-length, they are not superficial analysis. I could be writing this blog even if nobody would read it; I don't care about the non-critical audience that I don't have, I care about giving compelling reasons to come back to the critical (in the intelligent sense) audience that once in a while checks my blog.

Eddie said...

I didn't know that the microcode updates changed the stepping

howling2929 said...

Upss! My bad!

Further Clarifications on the Microcode Update:

I am not so certain anymore that the stepping # is altered. At least I am not able to Re-Find the references that I (think) read about it!

AMD has a similar feature in the K8. The relevant patent is USPTO 6438664 and is dated Aug 20, 2002, that is a full 8 years behind Intel (the feature may as well be present before that data, but it seems that the K7 and previous ones do not have it). So, if mister Ruiz moves forward a launch, there will not be mutiny anymore ;-)

Finaly, unlike Intel´s Microcode Updates, security in AMD´s is weak. Please check:
http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=2527&Thread=1&entryID=35446&roomID=11

Salud!

Anonymous said...

OK, so now that we've beat-up the microcode issue, I can only say that I see the value of Howling's arguments, but they aren't particularly compelling to me (as a customer/consumer in the market). There are, indeed, two sides to every coin... plus an edge that only has noticeable impact every so often. ;-)

I look forward to the discussion of new u-archs once every 2 years. Personally, I have my doubts about how likely that really is.

Howling, when you get to the point of posting on the "new every two years" topic, I'd sure like it if you'd also post your thoughts on why Nehalem has been rebadged so many times (it was once supposed to be a 10 GHz Netburst proc, IIRC), and also address some of the other items in this prior posting:

http://chicagrafo.blogspot.com/2006/04/are-you-worried-read-again-major.html#links
(not saying I agree with everything in the post... but the presentation of the timeline is certainly interesting... as would have been a mention re: the very long delay associated with AMD launching K8).

Frankly, I'd be very surprised if either Intel or AMD could do something so revolutionary every two years. I'm still leaning towards "evolutionary."

I will not be considering the non-MCM quad-core version of Core2 as a revolution. I also don't see the "K8L" (or whatever they're popularly known as now) as something that will be particularly revolutionary.

The closest thing to a revolution that we have right now is the Cell and (partly) Niagra. I think Torrenza opens doors for revolutions... but notice that Torrenza's premise is based upon a general purpose processor, attached to a very specialized processor. One needs massive software support for that kind of thing, if one wants to succeed on a massive scale.

howling2929 said...

My man, you did not get the point of the article. Microcode update or not, the coin has MORE than three sides. Each thing done, being technical, marketing or otherwise, has many ramifications, that affects other aspects, and many times, not so slightly.

The "new microarchitecture every two years" article will take a long time in comming (not that it is particularly difficult, but I am in the final term of my MBA) but I can advance a few things. It can be done, often times the changes will be evolutionary, but from time to time they will be revolutionary, and I see it more as an strategic move from Intel, than a technologycal one.

Anonymous said...

I mentioned 3 sides in relation to your 3 main points, one (Microcode) of which seemed less applicable in the end. I completely understand that the pictures is bigger than just the technological bits. But my read of your post is that you're focused on technological facets (IMC, MCM, Microcode).

Of course it's more complicated than that (I'd hoped the wink would have clued you in)... each one of those items (IMC, MCM, Microcode) has many facets of impact... but you chose to focus on a few facets in particular.

Personally, I feel that the "new u-arch every two years" announcement is a red-herring, until shown otherwise. To me, the strategy is to remind people that things like "kludge-cores" (as they're called here) are just a step in a grander scheme.

Yep... but today, they're still "kludge-cores" ... and no amount of gazing towards the cosmic unknown (years ago this would have been akin to the announcement of a 10 GHz Nehalem) is going to change that.

Anonymous said...

The one thing you forgot to mention about 2 die/one package vs native quad core is the economics in terms of yield and bin splits.

From yield perspective using 2 pieces of Si in one package, if you have a killer defect on a dual core wafer die you are throwing away 2 cores (smaller Si area) vs a killer defect on 4 core solution. As an example if you have 4 killer defects per wafer randomly distribute you can lose up to a max of 4 die/wafer with native quad core, where with 2die/2core solution you will lose a max of 2 "non-native" quad cores

In terms of bin split - how you bin out a native quad core part is basically limited by your worst performer of the 4 cores. The same is the case with dual cores except you are now limited by 1 of 2 of the cores; thus providing more opportunity to match up high performing dual core dies and thus getting higher bin split of high performing "quad" core parts.

I.E if you want a 3GHz quad core - in native solution you need all 4 cores above this level. With 2 die solution you simply need to match up two dual core 3.0 Ghz parts which you have a better probability of doing.

Anonymous said...

Your points on IMC vs FSB were good - at the time when AMD was developing K8, the memory roadmap was (and still is) relatively stable. Yet the even the move from DDR - DDR2 took a considerable amount of work to do this on the Athlon product.

If AMD truly becomes a technology leader there may come some more difficult calls on what memory to tie the IMC to on future designs. For example what if for some reason DDR3 flops and a new RAM type comes out - it means new IMC, new mask sets which are very expensive and delay in designing/validating entire chip as opposed to "only" doing this for a chipset.

Unfortunately the technical advantages are becoming more and more dominant (especially on multi socket scaling) where the added production flexbility/lower risk may no longer justify continued use of chipsets or you may suddenly see a split again on product design where server products use IMC where it is needed vs desktop/mobile not using it (this of course would go against Intel's recent strategy of using a common architecture to speed the turn time on new architecture development)

Eddie said...

The discussion about yields and indirectly binsplits was addressed by me (not Howling) in Intel's 65nm is just marketing

AMD's undisputed success at marketing dual cores at nearly double the price of single cores attests of amazing yields.

About "though calls" regarding the choice of memory support, I don't think that there will be much of a problem, AMD is evolving, and I believe the company, to truly modular microprocessors. I believe it because it fits in a grand strategy of taking functionality of coprocessors inside the µ-proc.

Remember that AMD brags about its capacity to turn mixes on a dime thanks to APM, I guess that if they wanted to do "ACMMP" (Anonymous Commentator Memory Module Protocol), it is a matter of inserting a module in the processors to be manufactured, APMing the exact amount needed, and that's it.

Was DDR2 something that took too much effort? I don't think so, I think that it was just as AMD says, it was introduced when it was cost-effective for customers.