AthlonXP L1 cache layout

[Conrad Song]

Has anyone taken a look at the strange layout of the AthlonXP L1 cache? Could this be that each block has it's own sum-address decoder?

http://www.aceshardware.com/read.jsp?id=45000368

[Moridin]

I’m not sure I see what you are getting at. To me like it’s only been moved.

[GiGNiC]

Originally posted by Moridin
I’m not sure I see what you are getting at. To me like it’s only been moved.

Heh ? the L1 didn't move I think, it was the L2 that did
about the L1 lay-out, I wouldn't know what's weird about it

[Arcanum]

The level1, as GiGNic pointed out is in the same place. The actual placement of the blocks looks about right too (obviously there will be slight changes due to the 0.13u shrink though).

In some ways it makes more sense for each block to have its own decoder as a single decoder which drives all of the memories in the L1 array wouldn't gain anything in speed - you would want to net split as soon as possible to minimise wire length to the repsective blocks (at the expense of higher routing congestion), but this would mean you would need larger drivers to drive the capacitive load on these nets (or more buffers on the nets), which either way will increase the signal propagation delay.

Duplicating the logic loses area, but gains speed.

On the other hand you still have to get the undecoded address to these duplicated blocks in the first place (and the above arguments on buffering still apply), so it may not be faster. Swings and roundabouts.

Its a messy floorplan in my opinion. The flow of data through the design isn't as coherent as Palomino now that the L2 caches have been placed at the bottom. I can see why they have done it, as a jump to a 512K L2 would mean it would make sense to tack the L2 caches on the bottom, however having the L1 DCache so far from the L2 cache isn't a good idea from a signal routing congestion and timing point of view.

If that was my floorplan I would want to shift the L1 DCache to be opposite the L1 ICache and above the other L2 cache block (keeping the floorplan more symetrical). I would then widen the chip horizontally and place the BIU, TLB, cache control logic and Tags (interesting that the TLB was done as custom arrays - probably CAM's - but the tags appear to be implemented as flops - although it is possible it is still an array of some kind) in between the L1 caches.

This would reduce signal routing lengths and also speed up data transfer between the caches and the BIU and between the caches and the execution pipeline. Ofcourse, most of these paths are probably non-critical which means you can then downsize the drivers or reduce the logic parallelism to gain area (so you win either way). Furthermore, doing this would enable you to better locate your datapath and control with respect to each other, improving performance.

It strikes me that AMD spent most of their time shrinking the design to 0.13u. They moved the L2 caches to cope with a planned future increase (Barton) and then obviously had to tweek buffers and the datapath after the shrink. I'm sure they would have wanted to improve the floorplan and possibly tweak the design more, but maybe they did not have the time.

The floorplan for Palomino is quite nice, but Thoroughbred just appears odd.

Perhaps they will change it for Barton?

Ofcourse, this is all only my opinion and as I don't know AMD at all so I could be well of base.

[Moridin]

Originally posted by GiGNiC


Heh ? the L1 didn't move I think, it was the L2 that did
about the L1 lay-out, I wouldn't know what's weird about it

Doh I stand corrected.

Does anybody know for sure which of the blocks on the chip are the I-cache, D-cache and tags? My guess would be the large dark area on the top right (on TBred) is the I-cache, below that right above the L2 is the D-cache and to the left of that is the tags. Does this seem reasonable or am I pushing the limits of what you can read into a photo like this?

Any that would mitigate some of the routing problems Arcanum points out. Assuming the instructions don’t get stored in the L2 very often the larger distance should not be much of a problem. Besides it needs to go through pre-decode anyway. The L2 is still close to the L1 D-cache so perhaps that isn’t an issue.

Anyway, I can’t help thinking I’m reading to much into this die photo…

[Arcanum]

I was making my comments based on the pic on the first page of the Tomshardware review:

http://www.tomshardware.com/cpu/02q2/020610/index.html

[GiGNiC]

One thing:

Thoroughbred seems to have no wasted space, compared to Palomino (above and below the L2-cache there)

And in tomshardware's review, I think they put an image of pally<=>tbred<=>barton in terms of size too ( http://www.tomshardware.com/cpu/02q2...ghbred-04.html ). what I found odd was that Barton was stated as 115mm² (35mm² for 256kb cache ?), and, the width of the core is same as tbred, but the height changed, I would conclude from that: another lay-out change ?
That would give 2 new lay-outs in about 6 months, freaky I say