NIOSII addressing for 32 bit wide SDRAM

Devices I am using are MT47H64M16

Configuration: 8 Meg x 16bit x 8 banks (ie. 1Gb, 128MB, or 64M x 16bit locations)

Row Addr: A[12:0] (8K)

Bank Addr: BA[2:0] (8)

Col Addr: A[9:0] (1K)

Total of row/bank/col = 8Kx8x1K = 64M x 16bit locations(according to the datasheet).

Now, given the way I have connected the two devices we still have the

same number of locations but now the density doubles since the

number of DQ's has doubled.

In order to access every location I need access to all address locations

(row,bank,col) but the datasheet for the controller says for its example:

>>>>>local_address[23:11] = row address[12:0]

>>>>>local_address[10:9] = bank address [1:0]

>>>>>local_address [8:0] = column address[9:1]

>>>>>The least significant bit (LSB) of the column address (multiples of four) on

>>>>>the memory side is ignored, because the local data width is twice that of the

>>>>>memory data bus width.

Is it not true that I need to be able to toggle the LSB of the column address

to access all the memory? To me it would seem absolutely necessary.

With consideration to my previous post:

I am trying to understand how the given accesses show up on the mem side.

The datasheet is does not really cover my case clearly with the aid of

timing diagrams.

Here was the data in question:

For writes(B = byte, L = local):

ACCESS BADDR BDATA LADDR BE WDATA

1 0 1 0 0F 0000000100000001h

2 4 2 0 F0 0000000200000002h

3 8 4 1 0F 0000000400000004h

4 c 8 1 F0 0000000800000008h

5 10 10 2 0F 0000001000000010h

6 14 20 2 F0 0000002000000020h

...

I would imagine that all of these would be single 32 bit accesses

to the memory(which is 32 bits wide) and thus from one cycle

to another the only things that should change would be the mem_DQ's and the

mem_addr. I would expect all other signals to behave the same

(until bank end is reached) so on the mem interface things should not

look different whether BE is 0x0F or 0xF0 but something is definitely

not functioning correctly here.

It is my contention that there are bugs in the controller for how

varying BE transfers are handled.

Here is some more data:

1: wrote 00000001, test_addr 00000000, read_val fffffffe, device 1

2: wrote 00000002, test_addr 00000008, read_val fffffffd, device 1

3: wrote 00000004, test_addr 00000010, read_val fffffffb, device 1

4: wrote 00000008, test_addr 00000018, read_val fffffff7, device 1

5: wrote fffffffe, test_addr 00000004, read_val fffffffe, device 1

6: wrote fffffffd, test_addr 0000000c, read_val fffffffd, device 1

7: wrote fffffffb, test_addr 00000014, read_val fffffffb, device 1

8: wrote fffffff7, test_addr 0000001c, read_val fffffff7, device 1

For this test I wanted to see what would happen to four BE=0x0F (x8) writes

if I followed them with four BE=0xF0 (x8 but with offset 4 addrs).

Here I do the 8 writes and then read them back at the end in the order

they were written.

Sure enough the data from 1-4 get stomped on by the writes 5-8.

If I read 1-4 back before the 5-8 writes then all is good.

It is almost as if the local_be(byte enables) are being completely ignored

by the controller.

For all accesses, local_size is 1 and local_burstbegin toggles for one cycle

with the local_write_req.

I welcome any feedback.

Thank-you.