Design Article
Memory subsystem validation through real-time compliance test and logic analysis
Barbara Aichinger, FuturePlus Systems and Brad Frieden, Agilent Technologies
4/16/2012 3:15 PM EDT
Detecting protocol violations with logic analyzer memory
Another approach to checking a memory system for protocol violations is through the use of a logic analyzer application called the DDR Validation Tool that is part of a DDR Protocol Compliance and Analysis Toolset. The validation tool searches through the deep memory capture of the logic analyzer for any violations. With a 1.2-V supply voltage and 2088 MT/s DDR3 rate, we found two violations on one of our systems (see figure 4) and the related trace samples were flagged.
That same system, also running DDR3 at 2066 MT/s and 1.2 V, showed a tendency to crash after the memory heated up. After a short period of running the Memtest #7 loop, the memory would stop doing Writes, and would continue to do Precharge, Refresh, and Read cycles for quite a while after the system had technically “died.” What were the exact conditions under which this catastrophic result happened? How could the evidence leading up to the crash be captured? A measurement challenge associated with this kind of situation is that the Precharge, Refresh, and Read cycles that continued after the crash fill up the logic analyzer memory and thus push out the data Read and data Write cycles of interest that preceded the crash. So what can you do in such a situation to capture the conditions that led up to the crash?
The answer is a timeout trigger available on a logic analyzer. We know Read or Write cycles should occur periodically or else there is something wrong happening in the system. A quick measurement, with a trigger on a Read cycle, yields a picture of typical data bursting. From that view, a "timeout" value for the trigger can be chosen, perhaps 20 times the time period of one of the longer Read or Write cycle separations in the trace. In our target, some periods of 1 ms between Reads or Writes were seen. We set up a trigger that watches for any instance in which more than 20 x 1 ms—20 ms—passes with no Write cycle, and if that happens, the logic analyzer is triggered (see figure 5) along with a captured trace (see figure 6). Pink color shading in the trace makes it very easy to see how Writes were occurring up until the “timeout” period before the trigger point, after which no more Writes occurred. It's easy now to look back in the trace for the sequence of events leading right to the crash, even up to speeds of 2.5 Gb/s rates.
Perhaps if Google were to run their study once again on the latest computer targets, with today’s more capable debug and test tools, they might once again confirm more memory issues happening than one would expect, but this time they might be able to say more about why. These new tools, used individually and together, greatly enhance the ability to validate and debug computer architectures that incorporate high speed DDR3 memories.
References
1. Schroeder, Pinheiro, Weber, "DRAM Errors in the Wild: A Large-Scale Field Study,"SIGMETRICS/Performance ’09 June 15-19 2009, Seattle, WA, USA.
About the authors
Barbara P. Aichinger is co-founder and vice president of new business development of FuturePlus Systems. She holds a BSEE from the University of Akron, Ohio and an MSEE from the University of Massachusetts.
Brad Frieden is a product planner for the digital debug solutions product line at Agilent Technologies. He has been with Agilent 27 years and involved in fiber optic test, pulse and data generator measurements, oscilloscopes, and logic/protocol analyzer applications. Brad graduated from Texas Tech University with his BSEE and from the University of Texas at Austin with his MSEE.
Did you find this article of interest? Then visit the Memory DesignLine, where we update daily with design, technology, product, and news articles tailored to fit your world. Too busy to go every day? Sign up for our newsletter to get the week's best items delivered to your inbox. Just click here and choose the "Manage Newsletters" tab.
Another approach to checking a memory system for protocol violations is through the use of a logic analyzer application called the DDR Validation Tool that is part of a DDR Protocol Compliance and Analysis Toolset. The validation tool searches through the deep memory capture of the logic analyzer for any violations. With a 1.2-V supply voltage and 2088 MT/s DDR3 rate, we found two violations on one of our systems (see figure 4) and the related trace samples were flagged.
Figure 4: Detection of protocol violations in the logic analyzer trace memory
That same system, also running DDR3 at 2066 MT/s and 1.2 V, showed a tendency to crash after the memory heated up. After a short period of running the Memtest #7 loop, the memory would stop doing Writes, and would continue to do Precharge, Refresh, and Read cycles for quite a while after the system had technically “died.” What were the exact conditions under which this catastrophic result happened? How could the evidence leading up to the crash be captured? A measurement challenge associated with this kind of situation is that the Precharge, Refresh, and Read cycles that continued after the crash fill up the logic analyzer memory and thus push out the data Read and data Write cycles of interest that preceded the crash. So what can you do in such a situation to capture the conditions that led up to the crash?
The answer is a timeout trigger available on a logic analyzer. We know Read or Write cycles should occur periodically or else there is something wrong happening in the system. A quick measurement, with a trigger on a Read cycle, yields a picture of typical data bursting. From that view, a "timeout" value for the trigger can be chosen, perhaps 20 times the time period of one of the longer Read or Write cycle separations in the trace. In our target, some periods of 1 ms between Reads or Writes were seen. We set up a trigger that watches for any instance in which more than 20 x 1 ms—20 ms—passes with no Write cycle, and if that happens, the logic analyzer is triggered (see figure 5) along with a captured trace (see figure 6). Pink color shading in the trace makes it very easy to see how Writes were occurring up until the “timeout” period before the trigger point, after which no more Writes occurred. It's easy now to look back in the trace for the sequence of events leading right to the crash, even up to speeds of 2.5 Gb/s rates.
Figure 5: Timeout trigger if no memory Write seen after 20 ms.
Figure 6: Resultant capture of system performance around the memory crash for which the last memory Write was seen 20 ms before trigger.
Perhaps if Google were to run their study once again on the latest computer targets, with today’s more capable debug and test tools, they might once again confirm more memory issues happening than one would expect, but this time they might be able to say more about why. These new tools, used individually and together, greatly enhance the ability to validate and debug computer architectures that incorporate high speed DDR3 memories.
References
1. Schroeder, Pinheiro, Weber, "DRAM Errors in the Wild: A Large-Scale Field Study,"SIGMETRICS/Performance ’09 June 15-19 2009, Seattle, WA, USA.
About the authors
Barbara P. Aichinger is co-founder and vice president of new business development of FuturePlus Systems. She holds a BSEE from the University of Akron, Ohio and an MSEE from the University of Massachusetts. Brad Frieden is a product planner for the digital debug solutions product line at Agilent Technologies. He has been with Agilent 27 years and involved in fiber optic test, pulse and data generator measurements, oscilloscopes, and logic/protocol analyzer applications. Brad graduated from Texas Tech University with his BSEE and from the University of Texas at Austin with his MSEE.___________________________
Did you find this article of interest? Then visit the Memory DesignLine, where we update daily with design, technology, product, and news articles tailored to fit your world. Too busy to go every day? Sign up for our newsletter to get the week's best items delivered to your inbox. Just click here and choose the "Manage Newsletters" tab.
|
|
|
|
|
Navigate to related information