AMD's Hammer Architecture - Making Sense of it All

Integrated Memory Controller & North Bridge

For years AMD has been branded as nothing more than another follower, always looking to Intel for direction. We already know the fate of the other followers from Cyrix to IDT, but if there was ever one design that clearly set AMD apart from the group that they are placed in it would have to be Hammer; and you're about to see why.

Now is as good a time as any to really stress the need for greater system memory bandwidth and reduced memory latency. Since AnandTech was started back in 1997 we've seen the transition from EDO to SDRAM, from PC66 to PC133, from SDR to DDR and even a few others such as VC and DRDRAM. We've also seen how DDR SDRAM alone can increase the performance of the Athlon processor by 20 - 30%. We've also seen how much latency can impact the usefulness of these high bandwidth memory solutions. Poor memory access latency is what crippled the original ALi MAGiK1 chipset which was out months before VIA could offer DDR for the Athlon. But if CPU manufacturers can design such powerful CPUs why is it that no one can design an efficient way to get data from memory to them?

Let's take a look at the path data must take in order to get from memory to the CPU. When the CPU executes a read from system memory the command is first sent over the FSB to the North Bridge of the chipset which then hands it off to its integrated memory controller. These initial steps alone house a number of potential bottlenecks. Although very rare (since FSBs and memory buses are usually kept somewhat in sync), it is possible for a lack of FSB bandwidth to slow down this part of the memory read. Much more likely are inefficiencies within the North Bridge and its memory controller which would add costly delays to the retrieval of data from memory.

Now that the memory controller has the read request (we're ignoring any buffers it has to propagate through, etc…) it is sent over the memory bus, to the memory and after a series of operations the data is found and sent back to the memory controller. The memory controller takes the data, hands it off to the FSB interface within the North Bridge and back to the CPU it goes.

There is very little you can do about the second half of this process since it deals almost entirely with the type of memory used and the operating frequency of the memory bus. What can be controlled however are the first and last few interactions which are governed by the chipset and the FSB.

We had been thinking of an intermediate L3 cache as a way of reducing latency and improving bandwidth utilization between the North Bridge and the CPU however AMD's thoughts were on integrating the memory controller into the CPU itself.

An overview of an AMD Hammer CPU

The benefits of a memory controller integrated into the CPU are tremendous; not only do you get much lower latency operation since all read/write requests no longer have to go through an external North Bridge before getting to memory but you also significantly reduce the chances of chipsets holding back the overall performance of a platform. We have seen countless examples of the Athlon being held back by platforms that are performing under par. At the same time, AMD has made it clear that they don't have the desire or the capability of becoming the chipset manufacturer that Intel is today. What better solution than to remove the problem altogether and integrate the memory controller into the CPU?

The Hammer CPU core interacts with the SRQ to send requests to the MCT/DCT through a Crossbar controller. We have omitted some information from this diagram for simplicity.

Thus the Hammer architecture calls for an integrated memory controller (MCT) and an integrated DRAM controller (DCT). The memory controller is a generic interface between the Hammer core itself and the DCT; this controller understands what memory is but isn't tied down to a particular type of memory. The MCT interfaces with the DCT which is much more specific and deals with specific types of memory. AMD could theoretically produce a Hammer with DDR SDRAM support and another with RDRAM support just by changing the DCT, but to end all speculation now, RDRAM would make very little sense on the Hammer. Remember that one of the downsides of RDRAM is increased latency in many situations; one way of hiding this latency is by pairing RDRAM with deeply pipelined CPUs such as the Pentium 4. It's obvious by now that the Hammer isn't as deeply pipelined of a CPU and won't have the clock speed to offset RDRAM latencies as well as the Pentium 4. This also makes AMD's decision to continue to support DDR SDRAM very sensible.