Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

The best way to thoroughly test the DRAM

Status
Not open for further replies.
J

jdhar

Full Member level 5
Full Member level 5
Joined
Aug 16, 2004
Messages
258
Helped
16
Reputation
32
Reaction score
2
Trophy points
1,298
Activity points
2,753
I designed a board with a Cyclone FPGA and SDRAM on it, and I would like to know the best way to thoroughly test the DRAM? I used a NIOS processor with on-chip memory to DMA a 1K block of data to and from the DRAM, and compare with the data on the on-chip RAM, but I don't feel that this is the best way because when I try to run code from the DRAM, it acts very erratically. I'm pretty sure it's a PLL timing-offset issue, so I will keep adjusting it.. but is there some good memory intensive C-code that I could use for testing?
 

Re: Verifying SDRAM

Perform a data retention by writing a PRBS and read it back every couple of seconds or minutes, and also perform a data line toggling test.
 

Verifying SDRAM

What is PRBS? I'm not sure how I should adjust the PLL phase.. I'm just trying every value and testing; some work better than others, but this is taking too long.
 

Verifying SDRAM

Thanks for that link, it's helpful!

There's one thing I find interesting; I'm using NIOS and Quartus.. if I powerup the board, and then download an image, it won't work... if I wait for a bit and re-download it, or keep trying, it does. ??
 

Re: Verifying SDRAM

jdhar said:
What is PRBS? I'm not sure how I should adjust the PLL phase.. I'm just trying every value and testing; some work better than others, but this is taking too long.
Click to expand...

The phase calculation is dependent on the trace length between the SDRAM and FPGA and the device dependent.

Try this article, https://www.xilinx.com/bvdocs/appnotes/xapp688.pdf

and try typing in google "delay board trace phase DCM sdram"
 

Re: Verifying SDRAM

About NIOS question... what image are you downloading ??? is not the memtest image is it ????
because it was compiled for X86 and will not run on NIOS.. you just have to get the idea about how to test de memory.
 

Verifying SDRAM

No, I wasn't trying to download x86, I'm aware that they are completely different. That's why I was asking if there was a good test already made for NIOS... if not, how I could write my own.
 

Re: Verifying SDRAM

now I understand,

bu you want to test all ram space or only the comunication chanell ??? like the data buses and address bus ????
 

Verifying SDRAM

Just the communication channel... the main thing I want to test is if the PCB and Phase-shift adjustment is correct... so I don't think testing 64 Megabytes will tell me any more than testing 1 Megabyte. The main thing I need to know is what input patterns should I generate, and in what order, and if I can do it with NIOS, or if I have to write RTL to directly use the DRAM controller.
 

Re: Verifying SDRAM

See previous message. Calculate the delay path in your board trace to determine the amount of shift required.
 

Verifying SDRAM

I have a phase shift calculated, and I have a board that appears to be working - what I need is a good way to verify it since I will be selling boards, and it's not enough for a small chunk of code to appear to be working fine.
 

Re: Verifying SDRAM

jdhar said:
I have a phase shift calculated, and I have a board that appears to be working - what I need is a good way to verify it since I will be selling boards, and it's not enough for a small chunk of code to appear to be working fine.
Click to expand...

My company qualify memory on the board by testing the dataline by toggling 1 and 0 to check stuck bits. And follow by writing a PRBS to the memory at every address location. The PRBS is kept in memory and read back at a predefined period (a data retention test). I usually run the test for 20 minutes to prove the data is still correct within the memory. But if the customer require a temperature test, you will have to hire an oven or buy one. Usually we run this for a bit longer.

This is testing a DDR, QDR, QDR2 on our boards.

If that doesn't answer your question, type in google "Data retention test memory" or something in that line.
 

Re: Verifying SDRAM

Then you have just to write these patterns .. 0101..01 to the address and then write 010...01 to these address ( in your address range ) and then read these address and you will see if the patern that you write are correct .. then you make the same at thesame address but inverting the patern that you will write .. then you verify it again in these new pattern, after that you invert the address bits and make the same procedure that you did to the first address.

when you use these all procedure you are verifing all lines in your PCB because you have changed it all , the address lines and the dada lines in both ways.

if you need more let me konw.
 

Verifying SDRAM

I understand how that is a good data-retention test, but does it test the PCB in terms of fast switching outputs? Here's a problem; I'm trying to implement a light-weight TCP/IP stack on a NIOS II processor. It's intended for the processor, so I know the code works.. but I am getting very erratic operation. For example, if I add more debug code (ie: add more printfs), the code responds differently.. then if I remove some debug code, I can ping the board, but it will crash on anything else. It doesn't act predictably every time, so I don't think it's a software issue. I also know it's not an Ethernet/PHY issue since I have a custom slim UDP stack I wrote, and that works without problems. So I'm thinking since both the MAC controller and NIOS processor can DMA to SDRAM, there may be a problem with timing in the DRAM core. This problem I am having is very erratic, and I can't find the source of it since the errors keep changing. Maybe my code works because it doesn't access DRAM as frequently as the stack...

How relaxed is the phase shift timing? for eg, does a phase shift have to be set with 0.5 ns accuracy, or will a range work (lets say from 2 to 4 nS)
 

Re: Verifying SDRAM

Can't you run the test without using the DMA. Create your own custom memory controller or download one from opencores and run at max. speed. At least you determine it works stand-alone instead of using the DMA.

My test uses our own core and is create as a user defined peripheral. The processor access a result register within the peripheral and print the results out on the RS232.
The tests has proven all the boards that have been shipped out.
 

    J

    jdhar

    Points: 2
    Helpful Answer Positive Rating
Verifying SDRAM

Well, the 'DMA' portion is part of the OpenCores Ethernet core, so I can't not include it; the DMA is a master, as well as the NIOS peripheral, and they can both access the DRAM. This is just an application I'm trying to run on the board however; this isn't the actual 'testing' application. I didn't have time to make a separate testing application, so when code was running, I assumed it was ok - but now I'm not sure since this application is failing.

Is your core something you could share with me, or is it private?
 

Verifying SDRAM

I have a question; for a test, would it be good if I use an on-chip RAM component and a DMA component to DMA lets say 8K of data to RAM? So I would load 8K of a test-pattern in the on-chip RAM (which is 8K in size), and then DMA an 8K block to each 8K block in DRAM - basically filling it up with that test-pattern? Then, after waiting maybe 5 minutes or so, I could DMA one block at a time back from DRAM into the on-chip RAM, and use code to check the test-pattern???

I'm not worried about testing shorted lines... I want to make sure I exercise the maximum speed of the DRAM at which the core will access it: ie; if my core is running at 50 MHz, I want to make sure I make as many accesses to DRAM as possible given that core frequency, and it seems like a NIOS DMA component is the best way to do this. If this works, should it guarantee that code running from DRAM (which would run as fast as possible I imagine since it's code running every cycle) will work??
 

Re: Verifying SDRAM

jdhar said:
Well, the 'DMA' portion is part of the OpenCores Ethernet core, so I can't not include it; the DMA is a master, as well as the NIOS peripheral, and they can both access the DRAM. This is just an application I'm trying to run on the board however; this isn't the actual 'testing' application. I didn't have time to make a separate testing application, so when code was running, I assumed it was ok - but now I'm not sure since this application is failing.

Is your core something you could share with me, or is it private?
Click to expand...

Sorry, it's private.

I think the test you mention should check the memory data but I would rather perform the test more frequently just to prove that it can be read several times.
 

Verifying SDRAM

Should I just repeat the read and verify part, or the whole thing including the write? So maybe read every minute or something like that?
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top