SAN JOSE – The Hybrid Memory Cube Consortium released to its members an initial draft of interface specifications for its 3-D DRAM memory stack. The group is now in final review of the specs with plans to release them publicly near the end of the year.
The group has so far defined two specifications—an interface protocol and a short-reach physical layer channel. The PHY is optimized for use connecting a memory cube and chips sitting multiple inches of printed circuit board traces away in a networking system.
The group will also define an ultra short reach PHY. It aims to extend less than three inches and is optimized to connect the cube with die, probably on a single multi-chip module.
Only members can get access to the initial drafts and provide input on them until the review process is complete and the specs are made public at the end of the year. The group is still open to accepting new members.
The group is led by Micron and Samsung. Other members include Altera, ARM, Hewlett-Packard, IBM, Microsoft, Open-Silicon, SK Hynix and Xilinx.
The spec is primarily targeted at high-performance networking, industrial, and test and measurement applications. IBM has also suggested it will use the cubes for high-end servers. The cubes contain both DRAM memory chips and a memory controller.
Previously, Micron said it will deliver 2 and 4 Gbyte versions of the cubes in early 2013, providing aggregate bi-directional bandwidth of up to 160 Gbytes/second.
Separately, the Jedec standards group is working on a follow on to the 12.8 Gbit/second Wide I/O interface that targets mobile applications processors. The so-called HB-DRAM or HBM effort is said to target a 120-128 Gbyte/second interface and is led by the Jedec JC-42 committee including representatives from Hynix and other companies.
Agreed stacking DRAMs has advantage. But I can't understand the rest. It is tightly coupled with the memory controller, so there is power and latency benefits. But it seems to force the processor away from the memory controller. Many processors have integrated DRAM controllers; so the stacking scheme seems to negate their advantage.
Why would you want a DRAM controller in a processor? The DRAM controller handles things like timings for the different row selects, bank access, refresh, etc. You want these as close to the DRAM chip as possible.
The reason memory controllers became integrated into processors is not because that's the best place for them - it was to avoid the extra chip, buses and latency caused by having the controller on a separate device between the processor and the memory (and sharing bus bandwidth with PCI and other buses).
The reason the controller is not in the DRAM chips today is because the chip process needed for controller logic is very different from that needed for the DRAM cells, so it would be hugely expensive to put them on the same die.
If you put the memory controller inside the DRAM cube, then the bus between the processor and the memory can be simpler and faster, and the memory controller can be more optimal for the dram banks it is controlling (including wider bus access and local cache inside the cube).
The potential here is not just to increase bandwidth, but also to lower latency - especially in servers with large memories and ECC.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.