AMD Stepping Information Decoded

[freecableguy]

s7e9h3n and I have been working on decoding the AMD memory controller/stepping information found on all new AMD processors for awhile now. This information is the combination of 5 letters and numbers found on the second line, immediately proceeding the year/week production code.

Example: CABNE

1st letter: "production/release code"
Pre-production or early samples have an "A" here where final production batches will be a "C" (for current chips). Some may recall that Venice samples where seen in the wild as "ABBLE" and current production runs are "LBBLE". While complete understanding of this is unknown at this time, it is clear that this has something to do with early samples.

2nd letter: "core cache code"
A = single core, 1MB
B = single core, 512KB
C = dual core, 1MB (each)
D = dual core, 512MB (each)

Note: 'Toledo' cores (1MB) with half the cache disabled will still be coded as "C". Therefore, you can see earlie 4600+ samples as ACXXX with only 512KB per core enabled.

3rd and 4th letters/numbers: "memory controller revision"
Works like a counter using all letter of the alphabet and digits 1-9. 3rd letter increments when running though all available 'steppings' as noted by the 4th letter.

FX-55: XXA2X
FX-57: XXBNX
FX-57 (new stepping)/FX-60: XXB2X
3700+ (new stepping): XXB3X
...
and so on...

5th letter: "revision code"
C = rev C (as in CG Clawhammers)
D = rev D (as in D0 for CBBID chips....)
E = rev E (as in the rev E 'San Diego' core)

-FCG & s7e9h3n

[DesertShooter]

Nice find m8!

[K.I.T.T.]

What about "K" as in KAB3E

[high5]

nice research guys.

as for Venice, i've also seen a YBBLE.

[starostise]

hi, do you have information about the four last letters of the stepping:

like 0540 APMW

[largon]

starostise,
Those 4 last letters are explained on the las page of this doc.

[high5]

hi, do you have information about the four last letters of the stepping:

like 0540 APMW

that was discussed on several occasions... but nevermind, here you go:



EDIT: largon was a bit quicker.

[kiwi]

Well, obviously only 3rd and 4th letters are useful

[largon]

Then we have the last row. That one isn't an easy one to decode...
My silicon gallery includes:

146 Venus':
1st:
1347827J50199
2nd:
1347827J50265
3rd:
1347827J50280

3000+ Winnie:
1197499B50126

AXP-M 2600+ Barton:
T873301G40109

AXP 2800+ Barton:
T866652F40227

The last 4-numbers can't be the core's serial number limited to a single wafer because Venices come with a batch nº as high as ~2400 and there are about 600 cores on one wafer.

[stone_cold_Jimi]

Eh...according to that, there shouldn't be "MW" endings either. My ancient Claw and my Opty 146's have MW endings. Or are fab lots and wafer lots simply different things entirely?

[s7e9h3n]

LOL...My dog woke me up since he had to go pee. Decided to drop by and see what's going on....There needs to be a couple of fixes in the original post. I guess I did proof-read it too well before I said it was OK to post This is what I see atm that needs revision:

1) The sample venices were mainly CBBLE, not ABBLE. The ones I debuted at XS were both CBBLE. The letter seems to refer to the a particular production run for that specific cpu. It has little/nothing to do with the memory controller itself.



2) There were no early 4600+ samples with the "C" code. FCG had one marked that way, but I have a feeling that there are very few, if at all any 4600+ Toledo Cores floating around. My 4600+'s, which are the earliest documented X2's, are both TRUE manchester cores with the "D" notation. The prime examples of the "C" 512K l2 x2's are the recent 3800+'s - many with the stepping CCBWE.

This cpu, was quite simply one of the strongest dual cores ever created, and that includes all the FX-60's. It's the WR holder for a dual core at 3.65Ghz @ 1.65Vcore and was run daily on OPB's single stage at 3.5Ghz @ 1.5Vcore. In addition, it's the first (and only AFAIK) cpu to score over 10K on PCMark04 and to this day still sits atop the Orb. Btw, on a stock mach2, I was able to get it to ~3.3Ghz @ 1.4Vcore. But what was most impressive about the cpu was the fact that @ -110C evap temps, if functioned just as well as it did @ +30C...........Which leads me to my next point about how this new-found information can be useful for spotting a cpu which *possibly* has better properties under the cold than others.........
Till now, it was common belief that cpu's which were cold bugged/non-cold bugged could be identified by it's ENTIRE stepping (meaning the first five letters of the second line), but if this theory holds true, all one has to look at is the 3rd and 4th characters of those letters/numbers. If you notice above, the 3rd and 4th characters of the 4600+ are "BH". Here's what temperature the little brother of OPB's cpu (exact same stepping) is able to function @:

Yes, that's -98C CORE temps you see Now I've been told by quite a few reliable sources that my FX55/56 (check my sig) has absolutely no cold bug as well:

Notice the revision of the memory controller? "BH". I've also confirmed with our fellow forum member GHZ that his 4000+ CABHE (which is F/S in the trading forum) doesn't show signs of the cold-bug as well. The memory controller revision possibly dictates a RANGE of temps that a particular cpu can operate at without worry of HTT problems. Now I haven't gathered enough evidence to say that this is totally foolproof, but from what I gather from both personal experience and evidence contributed by others, this for the most part is true. It seems as the revisions of AMD's memory controller have evolved, the less tolerant to cold they have become, e.g. CAB2E, CCB2E, KAB3E. Of note: The fact that a cpu doesn't have a cold-bug doesn't mean that it has limitless potential for OC. That seems to weigh on the quality of silicon which the cpu is built upon. Also, it seems that cpu's generally with lower batch numbers show less symptoms of the bug that the higher-numbered ones. There may be other factors which play into how a cpu is cold-bugged, but those are still unknown and haven't been identified as of yet.......

OK, I'm about to fall asleep at my keyboard after writing this so I'll continue in a bit after I get a couple of more hours of sleep

[largon]

Well, well BH-rev memctrl?

AMD techs have clearly been visiting Winbond fabs, no?

[high5]

good point Jimi.

my Sempron is also EPMW, LBBWE 0531.

[brechtvm]

CABQE

C > final production batches will be a "C" (for current chips)
A > A = single core, 1MB
BQ > new stepping
E > rev E (Revision Code)

0547

05 > The last 2 digits of the year in which the product was seal/molded
47 > Work week in which the product was seal/molded

GPAW

G > Alpha/numeric character for the day of the week during which the product was seal/molded.
P > Alpha/numeric character for the assembly location
A > Alpha/numeric character for the wafer lot seaquence for the day.
W > On rare occasions, a "w" may be added to the DC to designate that combining wafer lots is prohibited.

right ?

[s7e9h3n]

right ?

The "C" doesn't represent "Current chips", but rather a certain production cycle of the cpu. I'm not too sure how they're related, but I believe "K" and "L" share some sort of similarity as they are both more mature cycles of the older "C" cpu's. "Y" is one which I have no idea on FWIW, I have had a few Opteron ES cpu's which begin with the letter "F":

These cpu's never ended up making it to production in their current package. Instead they were released as Opteron 275's.

[SlackeR]

Nice decoding
Guess all our CABGE's just got a little better, eh?
But then again, they would prolly need massive temps to outperform good CABNE and CABYE's..

[brechtvm]

@ s7e9h3n : Thx !

[CrashOv3r1De]

Good job guys...Now the million dollar question is what FX60 stepping is least likely to be coldbugged or will handle the cold better?

[Fhqwhgads6680]

Wow this is some really good info, Wonder if we could get a list of all the mem controll revisions for the 90nm chips and start comparing cold bug data. If we can establish a good correlation between the different revisions we can possibly show people with subzero cooling how to better their chances of getting a cold loving chip. GREAT WORK!

[ozzimark]

hmmm, yes.. i smell a new database coming on

crash, i'm gonna venture CCBHE

[s7e9h3n]

hmmm, yes.. i smell a new database coming on

crash, i'm gonna venture CCBHE

I'm gonna go out on a limb and say a CCBHE FX60 won't be in the works for two reasons:

1. It's a version of the memory controller that seems to support only 1MB of L2 cache TOTAL. Past cpu's which have this stepping have ONLY been single-core San Diegos or 2x512K L2 Cache Manchesters. In fact, from observations, it looks as if AMD may have stopped producing Manchester cores all together as most, if not all, current 2x512K L2 cache cpu's are all Toledos (2x1mb cache w/ half the cache disabled).

2. AMD has moved much further down the road past the rev. BH memory controller and if everything stays according to plan, they won't create any new cpu's which revert back to this particular revision. A non-cold-bugged FX60 would have to be a brand-new revision which we haven't seen before since AFAIK, all the 2x1mb L2 Cache cpu's have a cold-bug to a certain degree.

There are a few things which are a mystery to me and quite possibly will never be answered - how does AMD "pick and choose" which revision memory controller makes it to production level? It's quite obvious that the memory controllers are designed long before the cpu's - that's why we don't see, for example, every rev. between BH and BW. AFAIK, there's no BK, BM etc. revisions on any cpu's. Those designs were most likely passed over in favor of revisions which we DO see -> BN, BQ, etc.....What changes are actually being made to the memory controller itself? If the reasons are able to be identified, then I'm sure the solution to the mystery of the cold-bug will follow closely behind. Also, in some instances, AMD has chosen to go with a revision of memory controller on certain cpu's and then go back to an "older" revision on subsequent cpu's. A good example is what happened with the a few FX57's (and maybe the s939 Opterons?)- Rev. BY cpu's were produced for a short time (OPB's CABYE 0524) and the revision which followed was CABNE (0528 and 0530). Why would AMD pass on a certain revision memory controller only to go back and produce it later?

Here's something I thought of while I was typing this Could it be possible the cold-bug may have something to do with a memory controller's ability to handle a certain amount of L2 cache? My reasoning is that there seemed to have been MUCH less of a problem with the cold-bug on cpu's with 1mb TOTAL L2 cache - be it a single, 1mb L2, or 2x512K L2. The problems in the cold became very apparent when the 2x1mb L2 cache cores appeared. I don't know of ANY non-cold-bugged rev. BW (CCBWE) cpu's and we all know how the CCB2E/CAB2E cpu's perform in the cold. Maybe the original design for the A64 memory controller only allowed for 1mb L2 cache to function properly in the cold and by tweaking it so now it can handle BOTH 1mb and 2x1MB L2 Caches, the result is a more severe cold-bug. I dunno....this is all speculation on my part

Well getting back to the original purpose of the thread, here are a couple more cpu's for your viewing enjoyment:

My FX55 Clawhammer - I still consider this, hands down, the strongest FX55 Claw I've ever seen. It was able to run @ 3ghz on a stock Opteron HSF 3dMark stable and not even break a sweat. (That was quite an accomplishment at the time). The memory controller on it was unbelievable - able to run a 28sec Spi1m @ 2900 on TCCD and garbage timings and as you all know.....no cold-bug to speak of:


My most recent dual core - ACBWE 4400+. Never tested on air - went straight to autocascade (before I had it modded for colder temps). Able to run dual Spi8m default speed @ 1.0Vcore. Cold-bugged @ ~-35 - -37C core temps.


I'll try to dig up a few more from my archives and show some more examples.....

[bachus_anonym]

There are a few things which are a mystery to me and quite possibly will never be answered - how does AMD "pick and choose" which revision memory controller makes it to production level? It's quite obvious that the memory controllers are designed long before the cpu's - that's why we don't see, for example, every rev. between BH and BW. AFAIK, there's no BI, BJ, BK, BL, etc. revisions on any cpu's. Those designs were most likely passed over in favor of revisions which we DO see -> BN, BQ, etc.....

What do you mean by that? Is that sentence true only to dual-core because we've seen Venice CBBLE or CBBID or Venus CABJE... The more I think about it the harder my feeling is that those two characters might not be exactly what you guys think... There is just gazzillion of combinations there on 90nm CPUs. It's just hard to assume that all of those are different revisions of memory controller... I think that there's something else in it... I don't know... Don't hurt me

EDIT: I smell that 3rd and 4th characters need to be treated separately...

[s7e9h3n]

What do you mean by that? Is that sentence true only to dual-core because we've seen Venice CBBLE or CBBID or Venus CABJE... The more I think about it the harder my feeling is that those two characters might not be exactly what you guys think... There is just gazzillion of combinations there on 90nm CPUs. It's just hard to assume that all of those are different revisions of memory controller... I think that there's something else in it... I don't know... Don't hurt me

EDIT: I have a hinch that 2rd and 4th characters need to be treated separately...

You're right about those memory controller rev. I guess I was just thinking of the Diego cores when I was mentioning the ones when didn't exist Are you sure there's a Venus CABJE? Or did you mean CACJE? There's not quite a "gazzillion" revisions. I have a feeling if you sit down and list them, you'll be surprised at how few revisions there actually are - especially considering the broad range of cpu's they cover - from winnies, to venices, to clawhammers, to diegos, to x2's, to opties (both s939 and s940), and now to rev e6 diegos and venices......oh...and don't wanna forget about the s754 cpu's as well

Edit: Original post edited for truth :P

[s7e9h3n]

EDIT: I smell that 3rd and 4th characters need to be treated separately...

I thought of that, but couldn't come up with anything that was workable in terms of what they could mean. I had a hard time associating the "B" for example on a CBBLE with the "B" from a CCBWE. What's your reasoning behind your assertion?

The more I think about it the harder my feeling is that those two characters might not be exactly what you guys think.

EDIT: Once again, I have to state that this is all assumption and none of it may/may not be fact. I figure that an educated guess is better than none at all

[chew*]

I'm gonna go out on a limb and say a CCBHE FX60 won't be in the works for two reasons:

1. It's a version of the memory controller that seems to support only 1MB of L2 cache TOTAL. Past cpu's which have this stepping have ONLY been single-core San Diegos or 2x512K L2 Cache Manchesters. In fact, from observations, it looks as if AMD may have stopped producing Manchester cores all together as most, if not all, current 2x512K L2 cache cpu's are all Toledos (2x1mb cache w/ half the cache disabled).

2. AMD has moved much further down the road past the rev. BH memory controller and if everything stays according to plan, they won't create any new cpu's which revert back to this particular revision. A non-cold-bugged FX60 would have to be a brand-new revision which we haven't seen before since AFAIK, all the 2x1mb L2 Cache cpu's have a cold-bug to a certain degree.

There are a few things which are a mystery to me and quite possibly will never be answered - how does AMD "pick and choose" which revision memory controller makes it to production level? It's quite obvious that the memory controllers are designed long before the cpu's - that's why we don't see, for example, every rev. between BH and BW. AFAIK, there's no BK, BM etc. revisions on any cpu's. Those designs were most likely passed over in favor of revisions which we DO see -> BN, BQ, etc.....What changes are actually being made to the memory controller itself? If the reasons are able to be identified, then I'm sure the solution to the mystery of the cold-bug will follow closely behind. Also, in some instances, AMD has chosen to go with a revision of memory controller on certain cpu's and then go back to an "older" revision on subsequent cpu's. A good example is what happened with the a few FX57's (and maybe the s939 Opterons?)- Rev. BY cpu's were produced for a short time (OPB's CABYE 0524) and the revision which followed was CABNE (0528 and 0530). Why would AMD pass on a certain revision memory controller only to go back and produce it later?

Here's something I thought of while I was typing this Could it be possible the cold-bug may have something to do with a memory controller's ability to handle a certain amount of L2 cache? My reasoning is that there seemed to have been MUCH less of a problem with the cold-bug on cpu's with 1mb TOTAL L2 cache - be it a single, 1mb L2, or 2x512K L2. The problems in the cold became very apparent when the 2x1mb L2 cache cores appeared. I don't know of ANY non-cold-bugged rev. BW (CCBWE) cpu's and we all know how the CCB2E/CAB2E cpu's perform in the cold. Maybe the original design for the A64 memory controller only allowed for 1mb L2 cache to function properly in the cold and by tweaking it so now it can handle BOTH 1mb and 2x1MB L2 Caches, the result is a more severe cold-bug. I dunno....this is all speculation on my part

Well getting back to the original purpose of the thread, here are a couple more cpu's for your viewing enjoyment:

My FX55 Clawhammer - I still consider this, hands down, the strongest FX55 Claw I've ever seen. It was able to run @ 3ghz on a stock Opteron HSF 3dMark stable and not even break a sweat. (That was quite an accomplishment at the time). The memory controller on it was unbelievable - able to run a 28sec Spi1m @ 2900 on TCCD and garbage timings and as you all know.....no cold-bug to speak of:


My most recent dual core - ACBWE 4400+. Never tested on air - went straight to autocascade (before I had it modded for colder temps). Able to run dual Spi8m default speed @ 1.0Vcore. Cold-bugged @ ~-35 - -37C core temps.


I'll try to dig up a few more from my archives and show some more examples.....

Steve what did that 4400 X2 do for stable clocks? and those 2nd line letters 2 and 3 would have scared me off.........Abbreviations for Cold Bug hehe