Barcelona die (11 metal layers, 283mm^2, 463M transistors):
Barcelona waffer:
Macro/micro-architectural improvements over K8:
Quad-core - Native quad-core design
- Redesigned and improved crossbar(northbridge)
- Improved power management
- New level of cache added, L3 VICTIM
Power management - DICE(Dynamic Independent Core Engagement) - PLLs for each core, clocked independently and varies clock speed depending on usage.
- ODMC power management: ability to shut down read channels if memory is only using writes and vice versa:
* Reduces the power consumption of the memory controller by up to 80% on "many" workloads.
- Aggressive grained clock gating
- Power management state invariant time stamp counter (TSC)
- Enhanced AMD's PowerNow - works independently without OS driver support
Virtualization improvements - Nested Paging(NP):
* Guest and Host page tables both exist in memory.(The CPU walks both page tables)
* Nested walk can have up to 24 memory acesses! (Hardware caching accelerates the walk)
* "Wire-to-wire" translations are cached in TLBs
* NP eliminates Hypervisor cycles spent managing shadow pages(As much as 75% Hypervisor time)
- Reduced world-switch time by 25%:
* World-switch time: round-trup to Hypervisor and back
Dedicated L1 cache - 256bit 128kB (64kB instruction/64kB data), 2-way associative
- 2 x 128bit loads/cycle
- lowest latency
Dedicated L2 cache - 128bit 512kB, 16-way associative
- 128bit bus to northbridge
- reduced latency
- eliminates conflicts common in shared caches - better for virtualization
Shared L3 cache - 128bit 2MB, 32-way associative
- Victim-cache architecture maximizes efficiency of cache hierarchy
- Fills from L3 leave likely shared lines in the L3
- Sharing-aware replacement policy
- Expandable
Independent DRAM controllers - Concurrency
- More DRAM banks reduces page conflicts
- Longer burst length improves command efficiency
- Dual channel unbuffered 1066 support(applies to socket AM2+ and s1207+ QFX only)
- Channel Interleaving
Optimized DRAM paging - Increase page hits
- Decrease page conflicts
Re-architect northbridge for higher bandwidth - Increase buffer sizes
- Optimize schedulers
- Ready to support future DRAM technologies
Write bursting - Minimize Rd/Wr Turnaround
DRAM prefetcher - Track positive and negative, unit and non-unit strides
- Dedicated buffer for prefetched data
- Aggressively fill idle DRAM cycles
Core prefetchers - DC Prefetcher fills directly to L1 Cache
- IC Prefetcher more flexible
* 2 outstanding requests to any address
HyperTransport 3 - Up to three 16bit cHT links
- Up to 5200MT/s per link
- Un-ganging mode: each 16bit HT link can be divided in two 8bit virutal links
- Can dynamically adjust frequency and bit width to save power
- AC mode (higher latency mode) to allow longer communications distances
- Hot pluggable
Barecelona pipeline (12/18 ALU/FPU stages):
CPU Core IPC Enhancements: Advanced branch prediction - Dedicated 512-entry Indirect Predictor
- Double return stacksize
- More branch history bits and improved branch hashing
History-based pattern predictor 32B instruction fetch - Benefits integer code too
- Reduced split-fetch instruction cases
Sideband Stack Optimizer - Perform stack adjustments for PUSH/POP operations “on the side”
- Stack adjustments don’t occupy functional unit bandwidth
- Breaks serial dependence chains for consecutive PUSH/POPs
Out-of-order load execution - New technology allows load instructions to bypass:
* Other loads
* Other stores which are known not to alias with the load
- Significantly mitigates L2 cache latency
TLB Optimisations - Support for 1G pages
- 48bit physical address (256TB)
- Larger TLBs key for:
* Virtualized workloads
* Large-footprint databases and
* transaction processing
- DTLB:
* Fully-associative 48-way TLB (4K, 2M, 1G)
* Backed by L2 TLBs: 512 x 4K, 128 x 2M
- ITLB:
* 16 x 2M entries
Data-dependent divide latency Additional fastpath instructions – CALL and RET-Imm instructions
– Data movement between FP & INT
Bit Manipulation extensions - LZCNT/POPCNT
SSE extensions - EXTRQ/INSERTQ (SSE4A)
- MOVNTSD/MOVNTSS (SSE4A)
- MWAIT/MONITOR (SSE3)
Comprehensive Upgrades for SSE - Dual 128-bit SSE dataflow
- Up to 4 dual precision FP OPS/cycle
- Dual 128-bit loads per cycle
- New vector code, SSE128
- Can perform SSE MOVs in the FP “store” pipe
- Execute two generic SSE ops + SSE MOV each cycle (+ two 128-bit SSE loads)
- FP Scheduler can hold 36 Dedicated x 128-bit ops
- SSE Unaligned Load-Execute mode:
* Remove alignment requirements for SSE ld-op instructions
* Eliminate awkward pairs of separate load and compute instructions
* To improve instruction packing and decoding efficiency
Most of the informations are from Ben Sander's presentation at AMD FPF 2006, but also there are other informations included from various internet sites.
Nice compilation gOJDO :!:
I dont pretend to understand what all that will mean in terms of processing power.
Your opinion if you please, do you think it will be the monster they claim ?
Yes, it will be a monster, for sure. It is a quadcore after all. How it will compete against current Core2 Quad depends on its the frequency. IMO, clock for clock both will perform similar. One will be marginally faster than the other. K8L will be a FPU monster and will spank Core2 in FP calculations, but it will loose in AL calculations. Both will have roughly same SSE performance.
Quote :
Also curious: expandable L3... at the fab or could a user plug in a microSD card next to the cpu socket 8O ?
The design of the L3 cache logic supports more cache. In 2008, the 45nm K8L shrink will have 6MB of L3 cache.
Mmm... very thorough list there... and from the looks of things, maybe K10 will be quite something when it is released. Let's just hope AMD doesn't botch the release though...
Dedicated L1 cache - 256bit 64kB (32kB instruction/32kB data)
- 2 x 128bit loads/cycle
- lowest latency
Dedicated L2 cache - 128bit 512kB
- 128bit bus to northbridge
- reduced latency
- eliminates conflicts common in shared caches - better for virtualization
Shared L3 cache - 128bit 2MB
- Victim-cache architecture maximizes efficiency of cache hierarchy
- Fills from L3 leave likely shared lines in the L3
- Sharing-aware replacement policy
- Expandable
Independent DRAM controllers - Concurrency
- More DRAM banks reduces page conflicts
- Longer burst length improves command efficiency
- Dual channel unbuffered 1066 support(applies to socket AM2+ and s1207+ QFX only)
- Channel Interleaving
I'm questioning the accuracy of this list because of a few odd details:
1) There was a source which misstated the amount of L1 cache as less than in the K7 and K8 cores. An AMD spokesperson came out and said the L1 cache would most likely be the same size as before. It's been 64K data + 64K instruction since the first Athlons.
2) Referring to L1 as 256-bit and L2/L3 as 128-bit doesn't make technical sense. Exactly what points do the data busses connect? I presume that the L1-L2 bus used to be 64-bit in K7 and soon it'll be 256-bit as in the P4/C2D, a healthy improvement. I also know that since the K8, the cache-IMC bus has been 128-bit, but we all know DRAM sends this data much slower than core clock rate.
3) L3 victim cache, as far as I know, is just another way to say exclusive cache. Both the external and integrated K7 L2 SRAM were also victim caches. There are advantages and disadvantages to this setup. Of course, considering the 2 MB of L2 in quad-core, an inclusive L3 at 2 MB would be of dubious utility.
4) The dual-controller IMC is a thoughtful design that I'd like to see some confirmation on. It seems hard to design without introducing latency relative to a synchronous dual-channel controller.
I'm questioning the accuracy of this list because of a few odd details:
1) There was a source which misstated the amount of L1 cache as less than in the K7 and K8 cores. An AMD spokesperson came out and said the L1 cache would most likely be the same size as before. It's been 64K data + 64K instruction since the first Athlons.
2) Referring to L1 as 256-bit and L2/L3 as 128-bit doesn't make technical sense. Exactly what points do the data busses connect? I presume that the L1-L2 bus used to be 64-bit in K7 and soon it'll be 256-bit as in the P4/C2D, a healthy improvement. I also know that since the K8, the cache-IMC bus has been 128-bit, but we all know DRAM sends this data much slower than core clock rate.
3) L3 victim cache, as far as I know, is just another way to say exclusive cache. Both the external and integrated K7 L2 SRAM were also victim caches. There are advantages and disadvantages to this setup. Of course, considering the 2 MB of L2 in quad-core, an inclusive L3 at 2 MB would be of dubious utility.
4) The dual-controller IMC is a thoughtful design that I'd like to see some confirmation on. It seems hard to design without introducing latency relative to a synchronous dual-channel controller.
1) It's still 64K/64K
2) The L1 is bidirectional so it can read and write 128bit blocks.
3) The L3 can dump cache anytime so it will be very useful. If the load is divided evenly across cores (close to even) then each core cn use and flush 512K without going to main memory.
4)The dual controller wil help with simultaneous accesses. If core 0 needs data and core 3 needs data they can both access RAM at teh same time.
Well, all I can say " HOLY SH!T!!!" ; that picture is the end of the world,....I feel bad,...I want this thing when it comes out,...but I know I con't have it that soon siiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiigh
Yes, it will be a monster, for sure. It is a quadcore after all. How it will compete against current Core2 Quad depends on its the frequency. IMO, clock for clock both will perform similar. One will be marginally faster than the other. K8L will be a FPU monster and will spank Core2 in FP calculations, but it will loose in AL calculations. Both will have roughly same SSE performance.
Yes, I would agree with this. I was initially only estimating a 10% improvement in Integer IPC. The talk before was that this was more of an upgrade to K8 than a new core. However, after seeing all of the changes, it clearly is a new core as different from K8 as K8 was from K7. I'm now thinking that it will get close to C2D in Integer IPC but I'm guessing there will still be times when 4 instruction issue and Macro Ops Fusion prevails. Since K8 is faster in FP now the new hardware will only make it that much faster. I agree that SSE should be pretty close although C2D could have a small advantage for some types of carefully tuned data and SSE instructions. Generally, higher clock should prevail.
The L3 is not simply exclusive as the L2 is. The L3 includes a sharing prediction buffer and is capable of guessing whether data should be shared. I believe it is initially liberal with instructions and assumes inclusive and conservative with data and assumes exclusive.
Also, the Crossbar isn't exactly the same as a Northbridge since it not only handles communication with the IMC but the HT links and data transfers between (among) cores as well.
There are only a few updates that I can see for the initial list beyond the correction that the L1 is the same size as for K8.
HyperTransport 3.0
The unganged mode has two channels, not two virtual channels. Basically, a single HT controller is capable of automatically sensing that each half is connected to a separate destination and can use them as two separate channels.
Also:
[list=1:6b8a038943][*:6b8a038943]Power Management Enhancements - Can dynamically adjust frequency and bit width to save power.
[*:6b8a038943]AC mode - Higher latency mode to allow longer communications distances. It is capable of auto-sensing this.
[*:6b8a038943]Hot Pluggable.
My compliments on the detail and accuracy of the list.
I thought that you were an Intel fanboy, but i guess I was wrong. Great info, it must have taken a great deal of time and effort to compile it. I'm sure a lot of people will appreciate it(if they are anything like me, eager to hear news about new technology). I hope AMD outperforms Intel, and than Intel again does the same to AMD, and we, the users, keep profiting from their competition Pozdrav!
