The semiconductor industry is served today by memory devices supporting various protocols, like DDR4, DDR3, LPDDR4, LPDDR3, GDDR5, HBM, HMC, etc. The trend is clearly to define application specific memory-protocols and in some cases, application specific devices. But developing many, and different, memory controllers IPs is resource and time consuming and not the best option for a vendor. For the chip-maker developing the System-on-Chip (SoC), the goal is to select memory protocol allowing integrating cost optimized memory devices, offering the best performance to cost ratio. If we look at the various, above listed, protocols, the DDR3 (DDR4) and LPDDR3 (LPDDR4) devices are offering by far the best cost/performance compromise. The DDRn or LPDDRn protocols support a wide range of applications, from low power mobile application processor to high performance, high bandwidth infrastructure application, like servers, storage or networking.
The question is how to define a unique memory controller which could be optimized to best support various applications like high-end consumer, mobile and infrastructure through parameterization. The memory controller IP is the most crucial piece of design in a SoC. If this IP fails, the SoC is simply not usable. That’s why the SoC chipmaker will take advantage of a unique memory controller design that is more robust, stable and easier to maintain by the IP vendor than a variety of hard macros. This paper summarizes a white paper from Cadence “Emergence of Segment-Specific DDRn Memory Controller IP Solution” and the technical data are related to Cadence’ memory controller IP products developed in 28 nm and 16 nm.
SoCs developed for networking applications requires the delivery of high bandwidth while running high performance computing and achieving large memory capacity. High bandwidth, along with large memory capacity and performance requirements, are expected to be directly translated to the memory controller IP and expected to deliver more data per cycle at the highest possible frequency. SoC targeting infrastructure segments have to provide a rich set of enterprise-class RAS (reliability, availability, and serviceability) features.
The protocols supported reduce to DDR3, DDR3L, and DDR4, as there is no need for LPDDRn support. The maximum data rate is 3200Mbps (note that overclocking is not supported in order to keep maximum data integrity and not impact the reliability). The data bus is set to 72 bits by default (it can be 16, 32, 40, 64 or 72 bits wide), and the address bus is set to 18 bits by default, allowing the user to access the largest possible memory space. Several features have been specified to best fit with the requirements of infrastructure applications, like DQ-to-DQS ratio (set to 4:1 compared to 8:1 in the other two configurations) to minimize the maximum skew between clock (DQS) and data (DQ). The memory controller supports per-rank-leveling (PRL) as well as write leveling for x4 DRAM to maximize data integrity, the goal being to optimize system reliability.
In the infrastructure segments, the CPU must use as much memory space as possible, and using dual inline memory modules (DIMM) is a must-have feature. The Cadence memory controller IP solution supports registered DIMM (RDIMM), unregistered DIMM (UDIMM) and load reduced DIMM (LRDIMM). In fact, these DIMM configurations are not supported in the other segments, the feature is infrastructure specific.
The white paper will tell you about the other two set of configuration features, defined for the mobile segment and for high-end consumer applications. Developing 100% application specific IP would be an ideal solution, but not realistic. Based on a unique architecture, this memory controller IP is highly configurable, this configurability allowing supporting the requirements of applications as different as servers/storage, mobile application processors or high-end consumer.
The white paper “Emergence of Segment-Specific DDRn Memory Controller IP Solution” is available on Cadence web site: http://ip.cadence.com/uploads/1102/wp-dip-ipnest-ddr-for-apps-final-pdf
By Eric Esteve from IPNEST