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
0.
   -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.

Hi John,

johnblake2000@gmail.com wrote:
> 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:
> 
[snip]

> 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
> 0.
>    -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.

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:

http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/8699cd7d6dc2a2b8/56f106a9f3f63641?lnk=gst&q=williams+ddr2&rnum=1#56f106a9f3f63641

Regards,

John

On Sep 8, 10:39 am, "johnblake2...@gmail.com"
<johnblake2...@gmail.com> wrote:
> I've been struggling for weeks to get sdram to work correctly on a
> newly designed board.
...
>    -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.

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

On Sep 9, 5:14 pm, John Williams <jwilli...@itee.uq.edu.au> wrote:
> Hi John,
>
> johnblake2...@gmail.com wrote:
> > 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:
>
> [snip]
>
>
>
> > 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
> > 0.
> >    -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.
>
> 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:
>
> http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/86...
>
> Regards,
>
> John

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.

On Sep 9, 5:23 pm, Alan Nishioka <a...@nishioka.com> wrote:
> On Sep 8, 10:39 am, "johnblake2...@gmail.com"
>
> <johnblake2...@gmail.com> wrote:
> > I've been struggling for weeks to get sdram to work correctly on a
> > newly designed board.
> ...
> >    -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.
>
> 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

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.