SDRAM slice on XS1 slicekit - lib_sdram 3.0.2 doesn't work?

[NickGManc]

I've been trying to get the SDRAM slice (XA-SK-SDRAM 1v1) working with lib_sdram 3.0.2 on an XS1 slicekit (XP-SKC-L2 1v2) using Community Tools 14.1.2 (Community_14.1.2 (build 17961, Dec-04-2015)).

The board works fine with the old SDRAM library, I am able to run both the read/write and the multi-client demos (using the Community tools 13.2.0), so I think the hardware is working as expected.

I have written a simple test program to write data to the SDRAM and read it back using the new library. When I run it, it always returns the same value: 67109888 (0x04000400):

Code: Select all

#include <platform.h>
#include <xs1.h>
#include <print.h>
#include "sdram.h"

#define MAX_BUF (16)

s_sdram_state sdram_state;


on tile[0]: out buffered port:32   sdram_dq_ah                 = XS1_PORT_16A;
on tile[0]: out buffered port:32   sdram_cas                   = XS1_PORT_1B;
on tile[0]: out buffered port:32   sdram_ras                   = XS1_PORT_1G;
on tile[0]: out buffered port:8    sdram_we                    = XS1_PORT_1C;
on tile[0]: out port               sdram_clk                   = XS1_PORT_1F;
on tile[0]: clock                  sdram_cb                    = XS1_CLKBLK_1;

void sdram_test(streaming chanend c_server)
{
    int i;
    unsigned buffer_W[MAX_BUF];
    unsigned buffer_R[MAX_BUF];
    unsigned * movable buffer_pointer_W = buffer_W;
    unsigned * movable buffer_pointer_R = buffer_R;
    // write data then read back to check
    for (i = 0; i < MAX_BUF; i++) {
        buffer_pointer_W[i] = i;
        buffer_pointer_R[i] = 0;
    }
    sdram_init_state(c_server, sdram_state);
    sdram_write (c_server, sdram_state, 0, MAX_BUF, move(buffer_pointer_W));
    sdram_read (c_server, sdram_state, 0, MAX_BUF, move(buffer_pointer_R));
    sdram_complete(c_server, sdram_state, buffer_pointer_W);
    sdram_complete(c_server, sdram_state, buffer_pointer_R);
    sdram_shutdown(c_server);
    for (i = 0; i < MAX_BUF; i++) {
        if (buffer_pointer_W[i] != buffer_pointer_R[i]) {
            printstr("Buffer mismatch at ");
            printint(i);
            printstr(" Wrote: ");
            printint(buffer_pointer_W[i]);
            printstr(" Read: ");
            printintln(buffer_pointer_R[i]);
        }
    }
    printstrln("Finished SDRAM test");
    return;
}

int main() {
    streaming chan c_sdram[1];
    par {
        on tile[0]: sdram_server(c_sdram, 1, sdram_dq_ah, sdram_cas, sdram_ras, sdram_we, sdram_clk, sdram_cb, 2, 128, 16, 8, 12, 2, 64, 4096, 4);
        on tile[0]: sdram_test(c_sdram[0]);
    }
    return 0;
}

Since the SDRAM slice uses an ISSI IS42S16400F 64Mbit SDRAM, I can see why the arguments have the values given, but for the row_words. Since the column address is 8 bits, why is row_words not 256? Is it because the buffers are 32 bit but the SDRAM is 16 bits wide? Changing row_words to 256 makes no difference to the result, however.

Has anyone had any success with this combination of hardware and library/tools?

[mon2]

Hi. Silly question but have to ask...if the older SDRAM library works, can you not continue to use the older (working) SDRAM library ?

Is there a specific reason to move to the newer SDRAM library ?

Do the XMOS supplied examples work with the new SDRAM library on your setup ?

The XMOS SDRAM Slice boards were fitted with assorted SDRAM devices. Have your defined the proper choice for your specific SDRAM component ?

PINOUT_V1_IS42S16160D
PINOUT_V1_IS42S16400F
PINOUT_V2_IS42S16400F

Recommend to test the XMOS supplied examples for the SDRAM use, verify that the examples are working well with the new SDRAM library before moving to your custom code.

[mon2]

Try with:

Code: Select all

    sdram_write (c_server, sdram_state, 0, MAX_BUF, move(buffer_pointer_W));
    sdram_complete(c_server, sdram_state, buffer_pointer_W);

    sdram_read (c_server, sdram_state, 0, MAX_BUF, move(buffer_pointer_R));
    sdram_complete(c_server, sdram_state, buffer_pointer_R);

Update - correcting my above post. The SDRAM user manual states your code should be ok - see page 4 & 5.

The documentation lists a difference in parameters to sdram_read & sdram_write.

From the SDRAM user manual:
https://www.xmos.com/download/private/l ... rc1%29.pdf

Code: Select all

sdram_read (c_server, sdram_state, bank, row, col, words, move(buffer_pointer_0));
sdram_write (c_server, sdram_state, bank, row, col, words, move(buffer_pointer_1));

later the API shows a different number of parameters for the same library functions:

Code: Select all

int sdram_write(streaming chanend c_sdram_server,s_sdram_state &state,unsigned address,unsigned word_count, unsigned *movable buffer)

int sdram_read(streaming chanend c_sdram_server, s_sdram_state &state, unsigned address, unsigned word_count, unsigned *movable buffer)

Are these typos ?

[NickGManc]

Thanks Mon2, I've tried many of the changes you noted but always get the same result. I've checked the SDRAM slice I have and it is definitely the F variant (in fact the F-7TLI version). I've used similar SDRAMs before with ARM chips without problems, but have found that matched trace lengths are important because of the very tight setup/hold times with respect to the clock. Termination is not a problem generally because of the short trace lengths.

I'm trying the later library to be compatible with a wider variety of SDRAMs and to be able to use the xCORE-200 processors. I like the server model implemented in the later library, mainly because it saves having to write something similar myself. Unfortunately the documentation is inconsistent in places, and AN10070 doesn't seem to exist.

Looks like I will have to delve into the assembler section to see if I can see any problems there!

[infiniteimprobability]

can see why the arguments have the values given, but for the row_words. Since the column address is 8 bits, why is row_words not 256? Is it because the buffers are 32 bit but the SDRAM is 16 bits wide?

Yes, this is a bit confusing. Unfortunately "word" can mean different things to different people. For the author, word = long word i.e. 32b. It is because the API deals with 32b words whereas the physical DRAM deals with 16b words, so the #define should be /2...

You shouldn't need to look at the ASM, but if you do then the latest update includes comments so you'll hopefully be able to de-cypher it.

https://github.com/xmos/lib_sdram/blob/ ... m/src/io.S

How did you download the library? was it via the libraries window or direct clone from github?

Let me check to see if this latest version is actually published...

[infiniteimprobability]

Are these typos ?

Yes - looks like the api was updated at some point to wrap up all of the SDRAM parameters into a struct, but the docs haven't been updated.

Also noted that the appnote doesn't exist - apologies, this has been raised internally.

I played around with this component recently and found that it does work OK (passed the test_bench app) on both XS1 (using A16 slicekit) and xCORE200 (not using slicekit... see http://www.xcore.com/forum/viewtopic.ph ... ilit=sdram).

The combination of hardware you are using should be fine (and I checked your init values and they look fine too..). Any progress on your side?

[NickGManc]

Thanks to InfiniteImprobability the problem is solved - upgrading to lib_sdram 3.1.0 does the job!