Issues and Limitations with DDR Memory

Catching one of the last flights out of Boston and escaping one of the many Nor’easters, I learned a great deal about Double Data Rate (DDR) memory while attending DesignCon 2015. Many people know a little about memory - it is ubiquitous and essential in computer architecture. It’s especially present in the backbone of the internet, servers. And with cloud computing being the latest and greatest thing out there right now, most companies want the fastest memory available since memory and the processor most likely determine the system’s performance.

Faster is always better, but unfortunately the increase in data rate also yields an increase in errors. Excessive commands that are common to the higher data rates of DDR can cause unwanted and undetected bit flips. This is an alarming issue because it is one thing to have an error, let alone errors that you don’t even know are occurring. The common applications for this technology further compound the distress because we are relying on these servers to store all of our data very securely and faithfully.  If there is a network error when posting a status update it isn’t that big of a deal, but if you are saving an important document or password and the system experiences an error your whole file could be corrupted and you wouldn’t know it until you try to access it at a later date and by then it would be too late. Any system is susceptible to this type of data corruption, because there is no industry defined test for these “Row Hammer” errors. There is a way to tap the system with DDR Detective (a FuturePlus Systems test tool) but until the Joint Electron Device Engineering Council (JEDEC) creates a specification to combat and or test this issue, any network can be affected by these undetectable errors and you wouldn’t even know it.

While it is important to have a standard with defined protocol and electrical specifications, it can be equally as imperative to have a well-documented procedure on how to test the necessary specifications. Uniform and repeatable testing methods make sure interpretations and assumptions of sometimes vague standards are the norm and not the exception. No stranger to standards development, the UNH-IOL would be very much able to test these shortcomings. Hopefully by DesignCon 2016 this issue can be resolved and FuturePlus Systems will be giving a presentation on how they eliminated the row hammer error. Until then, the UNH-IOL will be doing further research into this and other subject matters relating to the Open Compute Project (OCP) and will have representatives at the OCP Engineering Workshops and U.S Summit next week in San Jose, CA. Please contact David Woolf for any questions around topics we are tracking with the Open Compute Project.