Help getting sdram running with EDK.

I've been struggling for weeks to get sdram to work correctly on a newly designed board. I was hoping that someone might have some suggestions to help me out with my struggle here. This is what I am seeing:

I am using EDK 8.1 to build a Microblaze system with a sdram controller. The memory is a micron 48LC16M8A2tc-75 part.

I have verified that writes look correct using chipscope. I've carefully looked at all the parameters for the sdram in the EDK and verified in chipscope that I'm meeting the timing requirements on each parameter for the write side. So I feel pretty confident that everything looks good on the write side.

But I cannot verify what is happening on the read side because chipscope does not allow me to see the input from the sdram chip. I'm pretty sure that the problems I am seeing are happening on the read side.

I'm using XMD to test the memory by sending mwr and mrd commands. Since my chip has an 8 bit data bus, when I do a mwr 0x21000000

0x01020304 and watch what happens in chipscope I see the following: -The column and row get set correctly for the bank 0, column 0, row
  1. -Four bytes are written sequentially 0x01, 0x02, 0x03, 0x04 and DQM is active the entire time. -All the timing looks right.

When I do a read using mrd 0x21000000 I get back 0x01010101. If I do a mwr 0x21000000 0x02030405 (a 32bit write) and then a mrd 0x21000000 I will get back 0x02020202. I always get back the first byte that was written in the four byte sequence. If I do a mwr 0x21000001 0xFF 1 b (8 bit write) and a mrd 0x21000001 1 b then I will get back whatever was written to 0x21000000. This behavior is consistent across all addresses.

Any reads or writes will always do an active command, then a read/ write command which will set the beginning address and then will send four bytes, the 1st byte for the initial address and then 3 more bytes for the next 3 addresses using NOP's in burst mode. So there are a third of the addresses in the address space that I cannot directly address. I cannot find the setting anywhere that allows me to do a single beat operation as mentioned in the data sheet. It always defaults to burst mode.

The reason that I believe that the problem is on the read side is because when I power up the device the sdram should have random data in it. When I do a mrd on random addresses it will always come back as a random number repeated four times, like 0xADADADAD or 0x04040404 etc. If I'm not mistaken, the chances of always getting the same number in four different addresses is pretty unlikely. It should be random numbers for all four addresses.

Does anyone have any insight into what is happening here? The two questions that I have in addition are: -Is there anyway to see the input from the sdram chip using chipscope. I tried to look at the OPB bus but that did not show any useful information. It just showed the four same bytes showing up on the bus. -Is there a way to change how the sdram controller works so when I do a mwr 0x21000003 0xFF 1 b it actually selects bank 0, row 0, column

3 and sends 1 byte instead of selecting bank 0, row 0, column 0 and then sending 4 FF bytes while putting DQM active on the 3rd byte. That way it would work slower but at least I can verify that the problem is with burst writes and not something else.

Any help is sincerely appreciated,

John.

Reply to
johnblake2000
Loading thread data ...

[snip]

This sounds a lot like a problem I had last year - double check your ordering of the address lines out from the SDRAM controller - Xilinx numbers them backwards from the convention in memory device data sheets.

See this thread:

formatting link

Regards,

John

Reply to
John Williams

...

Your reasoning looks sound. It might help to look at the sdram data pins.

You can copy opb_sdram (assuming that is what you are using) to you r local pcores directory and modify it with an extra port to output the sdram data. Then you can look at it with chipscope_ila.

Alan Nishioka

Reply to
Alan Nishioka

Sure enough that was my problem, as soon as I reversed the address lines everything started working as I would expect! Thank you for saving me from spending more time figuring this one out. Now I just need to figure out why it is failing the provided memory test application. For some reason the i variable does not initialize to 0. It initializes to 1023 and then decrements instead of incrementing... I'll need to dig through the archives for this one and then possibly post another message if I can't figure it out. I have optimization turned off, not sure what else is wrong.

Thanks again.

Reply to
johnblake2000

Thank you for the help, I will definitely try adding a port the next time I need to look at the incoming signals. It seems so simple after someone points it out but I wasn't able to make that connection by myself. There is a lot to learn, sometimes it is overwhelming. Thank you.

Reply to
johnblake2000

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.