The IP market reflects new realities in DRAM control for SoCs

Please allow me to take a slightly contrary opinion here. It's true that configurability and flexibility of the controller solution are the key to being able to provide a memory controller IP that will meet the needs of most customers. There are some customers, about 20% of Denali's total memory controller customers, who want complete control over their memory traffic and who want to specify every activate command and the exact row, bank and column for every transaction. Typically these are networking customers who need to do this to allow for determinism of command latency, or else they are people doing MPEG codecs who want to specify their exact traffic for bandwidth reasons that are particular to the MPEG algorithm. For the customers that truly need that level of control, we provide a simple interface to the memory controller that allows them to access the external memory data exactly how they want and still gain some advantages of an advanced memory controller. There's another group of customers, again about 20% of the total, who have an idea of how their traffic should be based on some previous design or some academic idea of how memory traffic should look. Often this is based on how PC's access their memory, which can be inefficient. I love to work with these customers, because I can almost always find a way to give them better bandwidth, better latency for critical commands, or lower power by using a better paging policy, better arbitration, or a better scheduling algorithm like the ones contained within Denali's Databahn memory controller. The majority of customers, however, really just want to hook up a memory controller to their on-chip busses. For that, we offer a wide range of bus types and a way to connect busses of different widths and different timings. Working with the customer, we'll recommend one of three programmable arbitration mechanisms and then hook this up to our configurable controller on the backend which gives programmability over memory access policies - even when the controller is already in silicon. Databahn is successful here because we can offer a solution that is a custom fit to the customer's chip, but still built off of our baseline code that has more than 80 chips in silicon to date. It's this level of flexibility and configurability of the controller that allows us to have design wins even within the "I must do it my way" customers.

MOSAID's observations are very similar to those expressed in this blog entry. I believe the issue here is a chicken and egg scenario. Many chip vendors designed their own DDR controllers in the past and that has laid the groundwork for a very customized interaction with other chip functional blocks. As these chip architectures get reused, an off-the-shelf memory controller is unlikely to offer similar interfaces and functionality versus the previous home made solutions. This is not really a problem as long as the IP vendor offers flexible and configurable IP to permit the chip designer the option to do some or all of the memory controller design on their own. MOSAID?s DDR interface and controller IP is offered as PHY only, PHY plus basic controller elements or PHY plus full blown controller including multi-port arbitration and prioritization. For the later, there are virtually an unbounded number of ways for an IP developer to implement a port arbiter and prioritize a stream of commands. Such quality of service functionality is unique to every memory controller design that was built from scratch. The real question is will this ever change? Will the complete IP offerings eventually displace home grown functionality as the market progresses and chips continue to get more complex? For this to happen, I believe it would take increased cooperation between the IP providers and the system architects. However, this may be unlikely to happen if the system architects believe a key part of their internally developed IP is in understanding how to arbitrate and maximize the utilization of the memory resource.