The best way to thoroughly test the DRAM

Re: Verifying SDRAM

I use to have problems in one project years ago in that nature, in my case it was a timing problem you are probable making some concurrent code inside your fpga.

you are ina a very very slow speed to have problems with lines and buses, but when you put more code inside the fpga ( your debug code ) your rote inside the chip changes alot, thy search for these problem and to have more them one clock in your system, you can clock one in rising and another in flawling edges.

in may case may system only works when I put the debug code becose it changes the times delays.

Verifying SDRAM

At 50 MHz, I didn't think I would have any problems like this, that's why I'm not convinced it's hardware... but I don't know how to go about debugging a problem like this other than testing the DRAM using the above methods.

I couldn't completely understand your post, but it seems like you are referring to using multiple clocks.. I'm not sure how this would solve anything, but this would only be applicable for RTL, right? My "code" is C-code for a NIOS processor, not RTL, so I'm not sure how this would help me.

It *could* make sense how inserting C-code would increase the delays, making the system work, but again, at 50 Mhz, it's already quite slow... and this is someone elses TCP/IP stack (light-weight IP), so the code has been proven before.

Re: Verifying SDRAM

jdhar said:

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?

Click to expand...

Repeat read. Every minute should be okay. At least you are doing multiple read on the device.