September 8, 2008 -- The design of modern electronics equipment is a difficult balancing act. The need for fast time-to-market, high-performance, differentiation of advanced features, low-cost, and low-power bear down heavily on designers and architects. The use of pre-designed intellectual property (IP) is one way to get relief from the pressure. IP can simplify portions of the design that are important to the system, but do not need to be designed in-house. The use of third-party IP lowers risk and frees up internal resources to focus on other aspects of the design, leveraging core competencies on internal specialization and product differentiation.

IP has typically been developed and delivered as individual components for system-on-chip (SOC) designs, otherwise referred to as IP-centric solutions. Using memory interface IP as an example, a user could choose to integrate a memory controller, a physical layer (PHY) with a delay locked loop (DLL), plus input/output (I/O) drivers all from separate IP providers. Depending on the performance requirements for the end solution and the expertise of the designers integrating the solution, the final solution may or may not function correctly at the system-level.

System-level environments influence performance and functionality not accounted for in IP that is developed and delivered as individual components. Ensuring IP functionality through modeling and silicon test is no longer sufficient to ensure operation within the system. System-level failures can lead to significant cost increases associated with board, package, and potentially with chip re-design. Consequently, to ensure operability of the complete solution, high-speed interface IP must be developed in the context of the system.

Traditional IP engagement model

A typical SOC DDR memory interface solution consists of four key functional blocks: controller, PHY/DLL, I/Os, and the external DDR memory. The controller, PHY/DLL and I/Os reside on the SOC and the DDR memory device either resides off-chip in a module, or is mounted directly to the printed circuit board (PCB). A controller provides the decision-making and access-scheduling tasks, converting a memory access stream into available data for the user, and the PHY/DLL provides the interface between the memory controller and the I/O pads. The I/Os provide the signal-driving, shaping, protection, and connection to the off-chip memory components. A simple block diagram of a typical DDR3 memory interface is shown in Figure 1 below, illustrating how these key functional blocks interconnect.

Figure 1. Block diagram of a component level approach to interface IP.

A typical IP-centric approach treats each of these main pieces as a stand-alone block or component. In this IP-centric approach, features are optimized within each block with little notice of how the components will interact together and with the overall system. The focus of these blocks usually ends at the chip boundary, leaving off-chip concerns to the board designer.

The most important characteristics from an IP-centric approach to a SOC memory controller are those that demonstrate the component working successfully in a design. These characteristics typically include the following:

Full verification to minimize silicon re-spins. Code designed for re-use, easy integration, and simulation. Code designed to support industry standard flows.

In a PHY+DLL IP-centric approach, there are other important characteristics. In addition to those mentioned for the controller, the characteristics primarily revolve around the integration effort required when combining IP from multiple vendors, due to the specialized skills and experience required for DDR interface designs. DDR3 in particular creates new challenges including:

Effort to integrate the PHY+DLL with the controller. Integration of the PHY+DLL with the controller and I/Os requires experience in DDR interface design that the design team may not have, possibly increasing cost and schedules. Implementation of power and signal routing requires careful consideration in order to minimize die size, limit signal noise, and improve performance, requiring additional time and effort, and added pressure on schedule and cost targets.

A traditional I/O-centric approach to SOC design includes more characteristics in addition to those above. These characteristics include the integration with the PHY+DLL and the performance of the I/O signals on the external memory interface. DDR3 memories, with tighter requirements on the data capture window and timing budget, need complete signal integrity analysis. Some common concerns associated with an I/O-centric approach are:

Complicated layouts between the PHY+DLL require extra effort and expertise for minimizing die area, signal noise, and negative schedule impact. Difficulty determining the correct power/ground to signal ratio without a full understanding of the system-level environment. Managing the jitter and noise budgets separately from the PHY+DLL requires additional guard-banding that can further reduce timing budgets.

An alternate solution to address complete system needs

IP developed and delivered as components in an IP-centric fashion has proven successful in the past when used in systems with lower performance requirements of 800Mbps or below. However, when addressing the needs of high-performance interface IP, the entire system must be considered. The IP must address the needs of the SOC as well as the system, which includes the SOC-to-package and the package-to-board interfaces. An IP solution developed in the context of the system comprehends not only the functions required for each key component, but also how they are tightly integrated with each other and the overall system.

This type of interface IP not only focuses on the traditional needs (verification, re-use, compatible tool flows, etc.) but also includes the capability to address potential system-level issues such as power supply noise, simultaneous switching output requirements, and power management due to SOC and system-level design and manufacturing variations that can negatively impact signal integrity. The end result of implementing this solution is to achieve optimal performance, use minimal power, and reduce the total system cost for various system environments.

A DDR interface solution that addresses the needs of the complete system does so through each component, which together meets the needs of high-performance interface solutions, but are also individually architected to address various aspects of those system needs. Each IP component must be architected in the context of the complete solution, as system-centric with the end goal being to achieve the optimal system-level interface IP solution.

DDR controller solution architected to address system level concerns

A controller IP block diagram example is shown in Figure 2 below, surrounded by an arbiter on the left and the PHY+DLL, along with the external memory on the right. The controller referenced in this example uses a deep transaction look-ahead in conjunction with an intelligent scheduler to control the flow of data between the user interface and the off-chip DDR3 memory system.

Figure 2. Example controller block diagram.

The controller solution example delivers excellent memory efficiency, in part because of the very deep transaction look-ahead. Efficiency is defined as the percentage of the theoretical memory bandwidth actually delivered by the controller to the user interface. The scheduler can optimize transaction requests, reordering, combining and serving high-priority transactions first. The bypass path allows high-priority transactions to go directly to memory, skipping the scheduler to deliver very low latency for key transactions. The SRAM write-data block holds the write data prior to sending it to the DRAM, allowing the write transactions to be collected and serviced as a group, to improve access efficiency. The response engine assembles the result of the command request and attaches the order tag that accompanied the original command request, allowing out-of-order accesses to be re-ordered. This improves efficiency and increases overall system performance. The error check and correct (ECC) block is optional and supports error detection and correction, if required by the system.

In this example, the controller is optimized to meet a combination of performance, power, and area requirements. Since each feature of the controller is developed with these overall system requirements in mind, it is possible for the design to span a range of system options. For example, a controller that delivers high-efficiency can be used to create either higher system performance at any clock frequency, or lower cost. Higher system performance can be achieved when high-efficiency and high-performance memories are combined to create the maximum possible memory bandwidth. Lower system cost is possible when high-efficiency is leveraged to deliver the desired system performance at a reduced clock frequency, translating to lower system costs.

DDR PHY/DLL architected to address system-level concerns

The PHY portion of the PHY/DLL manages data flow between the external DRAM and the user interface. It is the job of the PHY to make sure data is transferred quickly and reliably. DDR3 devices use a point-to-point (fly-by) implementation, causing the delays from the controller to and from the device to vary from each data slice. Timing between each data slice must be automatically adjusted to compensate for these additional timing differences by the PHY/DLL using DDR3 read-leveling and write-leveling features.

Features that automatically calibrate for the system-level variations help to deliver a PHY/DLL solution that addresses potential system-level issues, removing the burden from the user to manage the response to changes outside the IP block. Some additional automatic calibration features in the PHY/DLL can be best delivered by leveraging an all-digital DLL implementation. For example, an all-digital implementation can reduce jitter by making changes to the digital delay 'taps' at specific times when the clock and data signals are not being used for data capture. In an all-digital DLL implementation, noise sensitivity is reduced and power supply noise can be controlled by not switching unneeded taps.

When migrating to new process nodes or libraries, an all-digital implementation can simplify these transitions by using an all-digital tool flow and standard digital components. These automatic calibration features make it easier to meet critical timing budgets over printed circuit board manufacturing variations, power supply variations, and changes between various manufacturers' device specifications, to improve time-to-market.

DDR I/O architected to address system-level concerns

DDR3 I/Os that have been architected to address system-level concerns provide significant benefits at multiple levels of the system design. I/O cells not only provide excellent performance characteristics on-chip, but can also mitigate potential noise due to simultaneous switching output (SSO) issues, among other system-level issues that can be related to the package and/or board. These benefits can translate into higher system performance and reduced development time.

Ideally, these I/Os would include all automatic calibration features and would require little or no user guidance for optimal operation. However, the wide range of potential system-level issues makes it difficult to develop an I/O solution where all the features are automatically calibrated. The following list illustrates some of the features that are automatically calibrated to work optimally in the users target application in conjunction with automatic features from other parts of the interface (such as read- and write-leveling, DLL jitter reduction and I/O-switching reduction, which are typically incorporated in the PHY) to address potential system-level signal integrity issues:

Reduced crowbar current: minimized on-time overlap reduces noise PVT compensation: adjusts to variations in process, voltage and temperature ZQ calibration: automatic DDR3 calibration on start-up

The following features illustrate some of the capabilities that can be optionally set by the user to address system-level noise and other signal-integrity concerns. The feature configuration can be determined during system bring-up or modeled via simulation.

Slew rate control: adjustable controls programmable by the user I/O drive strengths: extra settings to account for very slow to very fast transition requirements On-die termination: several user selectable settings for optimal flexibility Timing control: user programmable fine drive delay and drive/receiver duty cycle Voltage reference adjustment: user controlled ±delta to on-chip reference

System example for a high-performance implementation

IP developed in the context of a complete system provides significant advantages for high-performance or low-cost applications. It is not unusual for high-performance systems to also require wide data busses and multiple memory device ranks to boost overall memory bandwidth and depth. With large memory arrays, signal integrity, reduced timing budgets, SSO-related noise (at both the package and board level), and memory efficiency can all impact system performance.

Improved timing budgets and tolerance to environmental variation are built into these IP solutions making it possible to support large systems. The features in each major block work together to deliver an optimal solution. Important high-performance system features include:

Programmable slew-rate control to adjust the interface signals based on the load and characteristics of the interface traces. Programmable drive strength to adjust for the size of the memory array. Fine-timing control for edge placement to adjust for SSO noise. Low-power output options for non-critical signals. Minimized crowbar current to further reduce system noise. Optimized I/O switching (only switch outputs when a useful transaction occurs) by the controller to reduce noise. High-efficiency delivery by the controller, even in multi-rank memory systems.

Without the IP being architected to address potential system level issues the efficiency, signal integrity, timing budget, and simultaneous switching output requirements would make such designs difficult to implement within a tight time-to-market goal.

IP-centric vs. system-centric solutions

When memory interface IP is developed with features to address potential system level issues, the resulting signal integrity and overall system performance can be significantly improved. In Figure 3 below, the left diagram shows a marginal data capture window that can result when an IP-centric approach is taken. The resulting signal-integrity issues are left up to the board designer to solve and can impact performance, cost and schedule. With a system level approach to IP development, additional features and capabilities are designed into the memory interface IP (in the controller, PHY+DLL, and I/Os), and each block contributes to the performance of the overall system. This means that board design, manufacturing and test are all simplified, and performance goals are more easily met without sacrificing cost, power, or time-to-market objectives. The diagram on the right side of Figure 3 shows the improved eye diagram when system-level issues are addressed with specialized IP, developed to manage potential issues.

Figure 3. Eye diagram for an IP-centric solution (left) and a system-centric solution (right).

Summary

A typical IP-centric approach is no longer sufficient to meet today's aggressive goals for system performance, cost, power, and manufacturability. An approach that addresses system-level concerns and delivers a combination of system capabilities required to optimize the system for target markets is required. By optimizing each piece of the interface to work together, the IP provider can create a wider solution space for the designer to allow the right combination of tradeoffs targeting a specific system, whether it is a low-cost consumer or a high-performance networking application.

By Luigi Ternullo.

Luigi Ternullo serves as the senior product marketing manager of Virage Logic's application specific IP (ASIP) solutions, which include the company's DDR, PHY+DLL, and I/O products. Prior to joining Virage Logic in 2006, Ternullo held technical marketing management positions and engineering management positions at Agere, Vanguard International Semiconductor, and IBM. His range of experience includes SRAM and DRAM development as well as memory and logic built-in self-test (MBIST and LBIST). Mr. Ternullo has over 16 years industry experience and also holds over 25 patents in BIST and memory design, and has authored several BIST papers.