Similarities Between the Alpha EV7 (& EV79) and SledgeHammer.

[AGodspeed]

First go here.

AMD's SledgeHammer incorporates 0.13-micron SOI technology, an integrated memory controller, and in general, Alpha design ideas.

Compaq's EV79 processor is supposed to also include 0.13-micron SOI technology, an integrated memory controller, and obviously Alpha design ideas since it's an Alpha processor.

Compaq's EV79 won't be out until 2003/2004. AMD's SledgeHammer will be out approx. a year before EV79.

Just wondering what this means, if anything, about the way the server industry is headed in the future.

And btw, Intel bought the Alpha technology last June from Compaq, but why is Compaq still developing Alpha processors?

 

[Sohcan]

<< Anyone Else Notice the Similarities Between the Alpha EV7 (& EV79) to SledgeHammer? >>

Yes, it's been well known for a while...there's a reason Paul DeMone called Sledgehammer a "poor-man's" EV7 (not as a knock against Hammer). Though given the time frame, a comparison between EV7 (production 2nd half 2002 at 1.2GHz, .18u bulk CMOS) is more appropriate than EV79.

A quick and dirty comparison -
EV7:
- 4-way fetch OOOE superscalar
- 397 mm^2
- 4 communications links, each 6.4 GB/sec, one IO link at 6.4 GB/sec
- Integrated 2x64-bit RDRAM controller for 12.8 GB/sec of mem bandwidth
- 1.75 MB (IIRC) integrated L2 (plus a likely off-chip L3 on a daughtercard)

Sledgehammer:
- 3-way fetch OOOE superscalar
- ??? mm^2
- 3 communication/IO links, each 6.4 GB/sec
- Integrated 128-bit PC333 DDR SDRAM controller, 5.4 GB/sec of bandwidth
- ??? integrated L2



<< And btw, Intel bought the Alpha technology last June from Compaq, but why is Compaq still developing Alpha processors? >>

The EV8 team was transferred to Intel last summer, the EV7 validation, systems, and shrink teams are staying at Compaq until their jobs are finished.

 

[AGodspeed]

The rumored L2 cache size of SledgeHammer is 1024KB.

As far as the die size of SledgeHammer is concerned, is the pin count of a processor at all indicative of die size? I'm sure you're aware that SledgeHammer will have 940 pins.

 

[AGodspeed]

Btw, what bus will ClawHammer and SledgeHammer use. The Athlon uses the EV6 bus, so will Claw/Sledge use the EV7 bus?

 

[Rand]

<< The rumored L2 cache size of SledgeHammer is 1024MB.
>>



I'd like to grab one of those!
Sure you don't mean 1024KB/1MB?



<< As far as the die size of SledgeHammer is concerned, is the pin count of a processor at all indicative of die size? >>


It's often a rather vague indicator of relative die size, but it's certainly not infallible and I wouldnt judge the die size of the processor relative to competing designs by the pin-count.


As for the similarities between the EV7 and Hammer', well that's already been covered.... and when you think about it really isnt very surprising, Dirk meyer and his team have a lot of ex-Alpha talent among them.

 

[Sohcan]

<< As far as the die size of SledgeHammer is concerned, is the pin count of a processor at all indicative of die size? I'm sure you're aware that SledgeHammer will have 940 pins. >>

Eh, not really, there's too much else involved...certainly not a direct relationship, and you certainly can compare the # of pins of two different designs to determine relative die size (the EV7 has a 1443 pin package). Aside from any differences in L2 size, Sledgehammer has one more HT link than Clawhammer and a wider 128-bit memory bus. I'm looking at the HT bus architecture spec here, and it says that a 16-bit bi-directional HT link has 76 pins for data, control, and clock, and 27 pins for power and ground for 103 total pins. Starting from Clawhammer's 754 pin count, adding 103 pins for the extra HT link and 64 data pins for the wider memory bus gives you 921 pins. Add a few more for power and ground and you arrive at the 940 pin figure for Sledgehammer.



<< Btw, what bus will ClawHammer and SledgeHammer use. The Athlon uses the EV6 bus, so will Claw/Sledge use the EV7 bus? >>

Nope, it's all Hypertransport.

 

[AGodspeed]

Sure you don't mean 1024KB/1MB?

LOL, whopsa.

and when you think about it really isnt very surprising, Dirk meyer and his team have a lot of ex-Alpha talent among them.

Very true.

It's also interesting to note that AMD just recently acquired even more Alpha engineers from the API Networks HyperTransport team. AMD aquired most of API's HT team after API announced Chapter 11 bankruptcy earlier this year.

 

[BeauJangles]

<< The rumored L2 cache size of SledgeHammer is 1024MB. >>



Dear lordie! if that isn't a typo my new processor will have 1/2 the storage space of my dad's office computer just for it's L2 cache

 

[BeauJangles]

Oh and Godspeed, your slippin Allowing typos.... my my what is this world coming to?

j/k man. I look forward to your posts, they are always great

Thanks!

 

[AGodspeed]

The EV8 team was transferred to Intel last summer, the EV7 validation, systems, and shrink teams are staying at Compaq until their jobs are finished.

I see. Do you think there's a good chance that some form of EV8 will be implemented in Intel's P8 architecture?

I look forward to your posts, they are always great

Thanks!

Cool, thanks.

 

[Sohcan]

<< I see. Do you think there's a good chance that some form of EV8 will be implemented in Intel's P8 architecture? >>

The EV8 team is working on an IA64 design. It will undoubtedly receive their experience in circuit design, integrated routing and communications, and SMT (not to look down upon HP and Intel engineers, McKinley is a circuit design masterpiece). Itanium could stand to benefit a lot from multithreading, especially course-grained multithreading to reduce memory latency by hiding memory stalls. A joint U of Illinois/Intel team proposed an 8-way SMT Itanium using a McKinley-like microarchitecture to do speculative precomputation: an idle thread context is ran as a duplicate of another thread, ahead of its execution. This "forward thread" has the sole purpose of speculatively triggering caches misses for the trailing thread and thereby drastically reducing memory latency. Using chaining triggers on a single-threaded suite of benchmarks, simulations improved performance by an average of 70% with 8 thread contexts.