Comparing SRAM sizes 

When we compare the size of the Trace Cache on both Northwood with the size of a 256 kByte L2 Cache block then we see a significant increase.  If we may presume that Intel used it's densest type of SRAM for both large structures then we can obtain an indication of Trace Cache sizes in bytes as well.

                                Northwood Trace Cache:   256 kByte / 2.4   =     ~  106 kByte  +/- ?

                                Prescott Trace Cache:        256 kByte / 1.6   =     ~  160 kByte  +/- ?

 The Trace Cache CPUID

Northwoods Trace Cache contains 12 kOps.  That is 4096 lines of  3 uOps each. One line can be read each cycle. (The actual implementation may provide 6 uOps every 2 cycles, at least according to some patents)

The best place to look for the Prescott Trace Cache size in uOps is the CPUID table. The Trace Cache values were already published with the introduction of the Willamette and are still the same in the latest Prescott PNI document.

 In this table we find the following 3 entries for the Trace Cache. 

So it looks that we might expect a value of 71h in Prescott:   16k uOps.

Double odd or 4-way

So if we have 16k uOps  (16,384 uOps), how many lines of three uOps do we have?

16,384 / 3 = 5461.33333 lines? or maybe a whole number 5461 then ?  The 3 is already an awkward number. 5461 entries in a memory is something odd as well. It would be possible if the addressing was fully associative but the same CPUID table says that the Trace Cache is 8 way set-associative. What this means is that the number of entries divided by 8 must be a power of 2.  Now clearly 5461/8 = 682.375 is nowhere near a power of 2 !

Doing it four way

We get nice numbers again however if we presume that each Trace Cache entry now has 4 instructions up from 3.

The Trace Cache keeps the same 4096 entries but now with each containing 4 instructions. This would mean that the Prescott can send 4 instructions per cycle into the processing pipeline up from 3.  One can be happy if an average program reaches effectively 1.5  instructions per cycle so 4 per cycle is sufficient to fully support at least 2 threads.

Looking at the layout.

The pipeline stages following the Trace Cache affected by this change would be stages 6 through 9:  ALLOCATE, RENAME1, RENAME2 and QUEUE. These stages are located at the top-right corner of the die. We see that the whole layout has been thoroughly re-arranged, including a total vertical flip. The instructions flow from left to right. At the start we expect micro-code rom plus micro-code sequencer, A queue for incoming instructions from the Trace Cache and the Micro-code sequencer. The Allocate and Rename stages that reserve entries in various buffers further on in the pipeline (outside the area shown above). At the end we expect the Specialized queues for memory access and general integer and floating point instructions. Here ends the 4 way (3 way) division of equal instruction paths.

What goes in must come out:   4 way retiring.

A logical consequence of a 4 instructions per cycle Instruction Trace Cache is the ability to retire the same amount of instructions per cycle. This then at the very end of the pipeline. 

Making room for ...

The top two images below are from one of the Intel presentation sheets. They show what the layouter sees on his monitor when looking at the entire Floating Point unit of Northwood and Prescott.  The Prescott view shows how various units are intertwined. This is because the layout software was allowed to place cells anywhere it wanted in the entire area unlike the Northwood view where it was not allowed to place cells outside their bounding box. 

The two middle images show the same Floating Point units. The Northwood version comes from a high resolution die photo while the vague Prescott Floating Point unit was found on Prescott die photo shown during the spring 2003 IDF

The lower two images show the locations have changed. Again this shows that Prescott is a significant change from its Willamette/Northwood predecessors 

Most remarkable is what we may see at the location where we expect the Rapid Execution Engine and L1 Data Cache.Almost the same location that we know from the Pentium 4. The L1 Data Cache connected to the L2 with its very wide data bus is located close to the middle of the L2 cache. It seems that there are two identical copies, partly mirrored, next to each other. Now when we compared this with the central part of the Northwood's Rapid then we recognize a number of "hand-routed" macro-cells. These macro's are hand-routed because they are the highly speed critical cental units of the Rapid Execution Engine. Units like the ALU's the AGU's and the Bypass network.

Two copies of the L1 Data Cache as well?

It looks like there may be two copies of the L1 data cache as well. Both with the increased size of 16 kByte

The drawing below stems from a year old article that I never published. The only thing that has changed now is the new die photo of the Prescott. The 52,428,800 bit (presumably) L3 cache sram was the first shown 90 nm device. The L3 cache contains a significant amount of  extra logic and smaller memory that may be Tag Ram.

A lot of IO buffers

One eye catching detail on the L3 cache is the long row of little rectangles that runs along 90% of one of the die-sides.

If we zoom in then we can actually count them: 2 rows of 128 cells. These are most likely IO buffers. The fact that we now see a very similar row at the opposite side on Prescott's makes this only more likely.

Intel did mention that the Sram runs at a frequency higher as the then fastest Pentium 4.  This may mean that the old Xeon tradtion that the L3 cache bus runs at the same frequency as the processor core is continued with the Pentium 5.

One wonders what the relation is with the newly announced 775-contact pinless Land Grid Array (LGA) package with 297 contacts more as the current 478 pin package..