Published on January 21st, 2014
DDR memory testing includes a suite of electrical and timing test parameters that are defined in the Joint Electronic Devices Engineering Council (JEDEC). The JEDEC standard does not dictate how measurement is done but it provides a set of test specification that a memory device, DRAM should adhere to ensure compliance and interoperability in a memory system which includes computer system, servers and mobile devices. Testing these parameters manually is very time consuming and many designers today use automated DDR compliance test software from oscilloscope vendors to accomplish this task. As DDR memory speed increases from DDR3 to DDR4, the pass fail information provided by the automated compliance test is no longer adequate to help with the growing need to go deep in debug and characterization. A tool that is specifically designed to help with debug and characterization addresses this need and also provides a debug environment that can get the work done quicker and in a more efficient manner.
What needs to be in a DDR Debug Tool?
Read and write data separation
JEDEC specification defines test parameters as output and input cycles, meaning user need to be able to separate out read and write cycles to make measurement on the signal. Since the specification is written for the DRAM, most of the tests are written for input or write cycles. The first thing this tool needs to do is to make the read and write separation reliably. Most test algorithm uses the phase difference between the strobe (DQS) and data (DQ) to determine if it is a read or a write cycle. Read data is edge aligned with the strobe while write data is centered aligned with the strobe. As speed increases, the phase differences method may not be robust enough to accurately detect the bursts especially if the system has serious signal integrity issue to begin with. A read may be mistaken as a write cycle and vice versa causing the tool to provide pass result on invalid measurements. The tool does the standard read and write separation and shows the start and end of the read and write bursts to help user verify that the read and write cycles are separated as expected. To do this in a quick and efficient manner, the tool needs to allow for navigation to each read and write burst found in the trace. The tool would also report the total number of valid bursts along with number of read and write bursts found in the trace. This will allow the designer to decide if he or she needs to increase the activity in the system to get more data for the debug or characterization work.
|Figure 1 The DDR debug tool reports the number of read and write bursts found in the trace with markers to indicate the start and end of the burst. Navigation capability allows user to navigate to each bursts found the in the saved waveform traces of clock, strobe (DQS) and data (DQ).|
Statistical Analysis on Multi-bursts
JEDEC specification does not define the number of bursts that needs to be measured. In the past, most designers would just test one set of burst to get an indication if the system passes or fails compliance. The tests pass or fail depending on how much stress the system is under. A designer could increase the data transitions and in some cases, they will notice that there are fewer margins in the system. Almost every memory designer nowadays does margin testing. They are no longer just interested in pass fail information provided by the DDR automated compliance application software. They want to do statistical analysis on their signals to know if they have enough margins to push the envelope of their design beyond what is dictated by the specification. For this purpose, the designers need to collect as much statistical information as possible. The more bursts they analyze, the more confidence gained on their margin testing result. The debug tool needs to measure all the test parameters for all the bursts found in a quick manner to speed up testing time. Since the tool runs on saved waveform files obtained from the oscilloscope or saved compliance application software project file, there is no need for the oscilloscope to perform data acquisition or scaling to optimize the waveforms for measurement. This would greatly reduce testing time. The test result can be exported to a .csv format file for further analysis or reporting purposes.
|Figure 2 JEDEC measurement test result with statistical report of minimum, mean and maximum for user to perform margin testing in confidence. Statistical report can be exported to a .csv file for further analysis and reporting purpose.|
Also in margin testing, the designer needs to have a way to change the operating voltage and still make measurement at the correspondent reference voltage and AC DC input and output measurement levels as per the JEDEC specification. For example, normal operating voltage for DDR3 is 1.5V. For margin testing, the user may choose to lower it to 1.3V to see if the system can save more power. The tool would auto calculate the new measurement voltage levels and all the measurements will now run with the new measurement thresholds. The auto calculation part of this tool helps user translate the new AC DC voltage measurement thresholds seamlessly to reduce test setup time and also the need to refer to the JEDEC specification for formulas.
|Figure 3 New measurement thresholds are reflected when user changes the DDR3 operating voltage of 1.5V as specified in the JEDEC specification to 1.3V to test the performance of the system at lower power mode. The tool uses the formula as per JEDEC specification to auto calculate the 1.3V operating voltage AC DC measurement voltage levels.|
The measurement done in the tool is per JEDEC specification. The tests are classified into 3 categories – electrical, timing and eye diagram tests. Within these test categories, the individual tests are separated in terms of output or write and input read cycles. The tool has all these tests grouped in read or write cycles to prevent user from having to refer to the JEDEC specification before choosing a test to run. To make debug work more efficient, the tool marks all valid measurement found in the trace with markers to indicate the measurement thresholds in voltage and time. To help user narrow their focus to problem area, the tool will also mark the minimum and maximum measurement found in the test result. User can also navigate to each measurement to ensure all valid bursts are measured. The tool would also report the number of valid measurement found. Some systems have very few data transition so even though there may be lots of read and write bursts but if the data does not transition enough in the bursts, there may not be enough valid measurement to use for statistical analysis. For example, if you measure setup time, tDS on 2 sets of bursts with burst length of 8, you may find that there are only 9 valid measurements since the data only transitions 9 times in the 2 bursts. If your data is transitioning in every single bit of bursts, you would get 16 valid tDS measurements. While all these features may already be available as standard in the traditional DDR compliance test software, the tool adds visualization capability that would help educate and also give confidence to the user that the measurements are indeed valid. The screen with markers and measurement thresholds can be captured for reporting purposes. Since the waveform files are loaded as it is from previously saved waveform files either from a pre-configured oscilloscope signal acquisition or saved traces from the compliance application software, there would not be any alterations to the time and voltage scaling. It would all be according to user’s preference in terms of optimization for their reporting purposes.
|Figure 4 Measurement markers indicate the setup time measurement on write cycle, tDS with AC DC voltage measurement threshold points as per the JEDEC specification. Screenshot with waveforms, markers and measurement thresholds can be saved out for reporting purpose.|
In summary, due to the significant increase of speed and power efficiency in the recent memory technology like DDR4, the growing need for compliance testing task to migrate into deeper debug and characterization work has changed the testing framework and environment of a memory designer. Conventional DDR compliance test software with pass fail information can no longer support these additional tasks efficiently and effectively. A new DDR debug tool designed specifically to provide statistical analysis result on JEDEC measurements with navigation capability and markers to indicate problem area allows a memory designer to focus on problem area in a faster manner and gain higher confidence in their test result especially for margin testing. The tool also needs to be in a debug friendly environment or framework with intuitive user interface to help save setup time and speed up test time to help a memory designer save test time and ultimately overall design cost to achieve first to market goal.