SDRAM Slice on xCORE-200 USB sliceKIT Topic is solved

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

SDRAM Slice on xCORE-200 USB sliceKIT

Post by aneves »

Hello again.

I have an xCORE-200 USB sliceKIT and am trying to get the SDRAM slice card to work with a small demo program of my own. Here's the code:

Code: Select all

/*
 * SDRAM Playground.xc
 *
 *  Created on: Mar 25, 2016
 *      Author: Amandio
 */

#include <platform.h>
#include <xs1.h>
#include "sdram.h"
#include "memory_address_allocator.h"
#include <stdio.h>

#define BUFFERSIZE 1024
#ifndef SDRAMTILE
#define SDRAMTILE tile[1]
#endif

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

int CompareMovableBuffer( unsigned * movable buffer, unsigned * bufferCopy, unsigned length){


    for ( int i = 0; i < length; i++){
        if(buffer[i] != bufferCopy[i]){
            printf("buffer[%d] = %d bufferCopy[%d] = %d\n", i, buffer[i], i, bufferCopy[i]);
            return 0;
        }
    }

    return 1;

}

void app(streaming chanend c_sdram, client interface memory_address_allocator_i mem_alloc){

    s_sdram_state sdram_state;
    sdram_init_state(c_sdram, sdram_state);

    unsigned buffer[BUFFERSIZE];
    unsigned bufferCopy[BUFFERSIZE];

    unsigned * movable buffer_pointer = buffer;

    unsigned seed = 98;
    unsigned base_address;

    mem_alloc.request((BUFFERSIZE * sizeof(unsigned)), base_address);

    unsigned result = sdram_read(c_sdram, sdram_state, base_address, BUFFERSIZE, move(buffer_pointer));
    sdram_complete(c_sdram, sdram_state, buffer_pointer);

    for (int i = 0; i < BUFFERSIZE; i++){

        seed %= 0xFFFF;
        buffer_pointer[i] = seed;
        bufferCopy[i] = seed;
        crc32(seed, 77, 9890);
    }

    result = sdram_write(c_sdram, sdram_state, base_address, BUFFERSIZE, move(buffer_pointer));
    sdram_complete(c_sdram, sdram_state, buffer_pointer);

    for (int i = 0; i < BUFFERSIZE; i++){
        buffer_pointer[i] = 0;
    }

    result = sdram_read(c_sdram, sdram_state, base_address, BUFFERSIZE, move(buffer_pointer));
    sdram_complete(c_sdram, sdram_state, buffer_pointer);

    if (CompareMovableBuffer(move(buffer_pointer), bufferCopy, BUFFERSIZE)) printf("Arrays MATCH!\n");
    else printf("Arrays DO NOT MATCH!\n", BUFFERSIZE);


    while(1);


}

int main(){

    streaming chan c_sdram[1];
    interface memory_address_allocator_i mem_alloc_i[1];

    par{

        on SDRAMTILE: 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); // I don't know what these integer arguments mean yet.

        on SDRAMTILE: memory_address_allocator(1, mem_alloc_i, 0, 1024*1024*8);


        on SDRAMTILE: app(c_sdram[0], mem_alloc_i[0]);

    }
}

In a nutshell, all I'm doing is allocating two arrays whose length is determined by the #define BUFFERSIZE. I'm generating random values in each index and writing one to SDRAM, zeroing it all out, and then reading it back. I then compare this buffer with the copy I made to see if they match.

Here's a picture of my setup:
[thumbnail]https://www.anony.ws/i/2016/03/29/0329161643.jpg[/thumbnail]

I've got the SDRAM sliceCard connected to the Type 3/7 connector and I have the jumper on J14 across pins 1 and 2. In the code above I've place all port definitions and tasks in tile 1 since that is where the pins on the Type 3/7 connector map to.

My problem is that if I define BUFFERSIZE to anything greater than 13, I start to see differences in the array read back from the SDRAM slice card. For example, if I define BUFFERSIZE to be 14, then the last index fails the match. If I define it to be 1024, I can see that some inidices after a certain point contain garbage values but eventually pick up from where they left off so it looks like indices that do match are now offset.

I uploaded the project to my Google Drive if anyone wants to take a look at it:
SDRAM_Playground

I'm using lib_sdram v3.0.2. I followed along the lib_display_controller which uses sdram heavily as guidance. I couldn't find anything too different in how it is accessing the sdram server.

Has anyone had much luck and/or experience using the SDRAM sliceCard who can give me some pointers?

Thanks!


View Solution
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi aneves. While we do not (yet) have the XCORE-200 USB SliceKit, we do recall spending many moons on reviewing the SDRAM code to port onto the startKit. Actually made some excellent progress but is still not ready for public release.

Summary: The SDRAM code is written very tightly and in a style that only a siamese twin would understand.

From a quick review of the related documents, the XCORE-200 is a different layout than the older SliceKits (on which the SDRAM was developed) and you are on the right track with the 3/7 choice. However, recommend that you use Type 3 mode for your slot since this mimics the older SQUARE mapping. The use of Type 7 alters the port widths and will break other code inside module.

Respectively, the SDRAM slice is SQUARE slot compatible. Use the mappings for the SQUARE mapping but be sure to select the proper Tile for this use and this should fix the observed issues.

In short, the SDRAM is being bit banged to refresh, Read, Write commands and data using the assorted port pins. It is not trivial to alter the port pins unless you wish to review the entire source code which is in XC and assembly language.

If your port pins are not spot on with the access to the SDRAM then you will enter the fun zone with your memory storage and retrievals.

The best advice we can offer with XMOS devices is to take what is deemed to be working code and change as little as possible and move on to work your task. Should be fine on Type 3 = SQUARE (watch the Tile #) or even STAR, TRIANGLE emulation using Type 1 or 2, respectively (again, watch the Tile # else you will be shooting blanks :)

Oh the fun of that SDRAM on startKit review...
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Hi,
I spent some time recently looking at the SDRAM library.

First - mon2's comment
Summary: The SDRAM code is written very tightly and in a style that only a siamese twin would understand.
is accurate.

It's highly optimised using some tricks to get the burst rate to be 1 I/O per 2 core clocks, which using a 16b buffered port gets you to 1 SDRAM clock per core clock. Hence 62.5MHz support. Unfortunately it uses assembler, and assembler that uses some odd addressing modes, loop unrolling, heavily re-uses registers and is low on comments. It also limits row size to 8b (64Mbit), again due to ISR addressing limitations.

I've re-written the ASM part to support >8b row addresses and can confirm it works. If you don't need >8b row address than what's published is fine and works on xCORE200 OK.

HOWEVER.. I also discovered that SI on the XU216 Slicekit is not good enough to support SDRAM. I was unable to get any of the slots working due to heavy cross talk, I believe between address lines and clock. Lots of reasons for this - layout, termination (none!), stubs (not point to point), no impedance control and use of buffers on some slots. This meant I couldn't even get it going at 5MHz (which should be valid) because the issue was clock related..

I was able to get it to run on the XL216 slicekit in slot 2 (need to turn off xscope) but this is marginal.

So the short answer I'm afraid xCORE200 slicekit and SDRAM slice is not a happy marriage. I guess this is what you get when you try to make a dev kit very flexible... We have some internal boards where the I/O is direct to an SDRAM chip using nice point to point, and it works just fine.

So I can reassure you that if you designed a PCB with the normal attention to SI that you would apply to a 50+MHz digital design, lib_sdram will work.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Thanks infiniteimprobability for your comments. While we were reviewing the SDRAM code, we decided to design a few variances of the SDRAM slice boards to allow for signal probing, etc. and applied the standard SDRAM package as well as a BGA footprint. However, we have not yet tested the finished PCB designs. Let us hunt around once I reach the office to see the current status of the designs. If there is a general consensus that the designs are satisfactory, we can push to prototyping our versions of the designs.

One comment: The original XMOS SDRAM slice board = 2 layers and we did not agree on this for our PCB layout. Respectively, our versions are 4L which should provide for a cleaner SI. The goal was to offer as an open source design so no issue to share more details soon.

Kumar
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Post by aneves »

So the short answer I'm afraid xCORE200 slicekit and SDRAM slice is not a happy marriage.
I gotta say, this experience has been frustrating. The whole reason my company purchased the xCore-200 USB sliceKIT was to evaluate a USB controlled solution with SDRAM. I chose this dev board after documentation published by XMOS explicitly stated the two were compatible:

XMOS Board Selector
Image

sliceKIT selector
Image

What else will I buy from XMOS only to discover it doesn't really work as advertised?

Who at XMOS do I contact to receive a refund?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Brother, we feel your pain. Our 2 bits (putting on my Dr. Phil hat)...XMOS is very unique technology. If you are working with audio which you appear to be, then this is really THE choice of a solution. XMOS is the king of the audio world and we are now wondering if we should be doing the same after learning of the incredible price points high end audio demands. No doubt you can stitch other components like an external USB to xx bridge onto this CPU to perform the same task but with some investment of time and a few bandages later, you should be able to accomplish your goals using a single controller. Very few silicon vendors can claim to cascade more CPUs to continue to parallel process their code if they should run out of code space and/or I/O. The logical CPUs are low latency and offer many features that cannot be matched at similar price points.

While waiting on an official response to your post, would you please try the following ?

https://www.xmos.com/published/sdram-de ... 1.1.0rc0.a

The above landing page notes the use of the STAR slot = Type 1 on your XCORE-200 SliceKit

Reference:
https://www.xmos.com/download/private/x ... 1v0%29.pdf
* page 5

Please select your exact target board when testing this IP.

Very curious to learn of your results using the same SDRAM board on your slicekit. Please post your results at your earliest convenience. If the demo runs, can you expand the code to R/W more locations of the SDRAM. From our memory (no pun), believe you can dial up the SDRAM clock speed so it should be ok to slow down the access through this source code to suit the sliceKit.

References:
https://www.xmos.com/published/slicekit ... imple-demo

https://github.com/xcore/sc_sdram_burst

The following is the code we used for our testing on our standard (XS1 based) SliceKit:

https://github.com/xcore/sc_sdram_burst ... sdram_demo

Also, here is a snap shot of our (pending) version of the same design (SDRAM slice board on 4L PCB):

Image


Corrections to my post:

1) The SDRAM default IP references the use of the STAR slot (older XS1 SliceKit name). No such slot equivalent exists on the XCORE-200 SliceKit.

What is Type 1 slot referencing inside the XCORE-200 SliceKit manual ?

2) Test with the SQUARE slot equivalent (XS1 SliceKit name) which is Type 3 on the new XCORE-200 SliceKit and will link with Tile[1].
Last edited by mon2 on Wed Mar 30, 2016 9:10 pm, edited 1 time in total.
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Post by aneves »

Hi mon2,

Thanks for taking the time to reply and for trying to help.

From what infiniteimprobability said earlier, it sounds like it doesn't matter what code I use to try and talk to the SDRAM sliceCARD. The xCore-200 USB SliceKit just won't work with the SDRAM SliceCARD due to the layout issues with the dev board he listed:
HOWEVER.. I also discovered that SI on the XU216 Slicekit is not good enough to support SDRAM. I was unable to get any of the slots working due to heavy cross talk, I believe between address lines and clock. Lots of reasons for this - layout, termination (none!), stubs (not point to point), no impedance control and use of buffers on some slots. This meant I couldn't even get it going at 5MHz (which should be valid) because the issue was clock related.
Another limitation I was not aware of:
It also limits row size to 8b (64Mbit), again due to ISR addressing limitations.
Is that to say that the SDRAM library is not compatible with memory capacities greater than 8MB?

Our goal was to be able to address hundreds of MB. Will this not be possible with the current release of lib_sdram?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

I've re-written the ASM part to support >8b row addresses and can confirm it works. If you don't need >8b row address than what's published is fine and works on xCORE200 OK.
Believe he has now updated the code (at least at XMOS) to break this limitation but do not believe it is posted yet on Github.

Please consider to test the SDRAM slice using their demo code on your Type 3 slot since Type 1 is not bonded out yet is mentioned in their XCORE-200 SliceKit docs :(

Type 3 slot = Tile[1]

Since you have tools at your side, worth a test. I do see in the schematics that a buffered clock of 25 Mhz is fed into each of the (slice) slots. We can vouch that the older XS1 SliceKit can work with the SDRAM module but we ran only the sample example tests which will write a few values into the SDRAM and then read back to compare. We also recall running the bench marking test with success but again on the older XS1 SliceKit.

----

Sorry - did not reply to your question on hundreds of MB access.

We are far from being SDRAM experts so not sure of your options unless you consider traditional CPUs and/or FPGA solutions. But then you will most likely not have the benefit of the assorted and available audio related IPs that XMOS offers. The parallel processing nature of these devices is a key selling point and couple that with low latency. IP development time in our opinion is a weak point but may be considered as a barrier to entry for your competition. The compiler is free and for the most part, able to crank out working code.

Only XMOS can define what the next version of the SDRAM code will support as a MAX address range. Perhaps they can supply this detail soon. Personally, found the SDRAM code to be very convoluted when it was reviewed for the startKit port. The startKit has a CPU bonded to a PCIe connector but the ports are not contiguous so there is a lot of thought that must be considered to allow the SDRAM to operate correctly yet continue to refresh correctly, etc.

A quick suggestion is that you can stitch as many of these devices together as you wish and the devices can communicate with each other using LVDS interface (recommended) or if close enough, without such external transceivers. Respectively, you can send/receive data between any of the connected CPUs. Moving forward, you could consider to marry a SDRAM device to each CPU and respectively each CPU would nurse the refresh of the local memory device. As each device can do much more than baby sit the SDRAM, the free extra tile (if you choose such a component), could bit bang some other function(s) for your project. As noted, XMOS is different and there is a learning curve. There are more positives than negatives on this product line. No doubt, not perfect but the silicon is working and key OEMs are consuming them in millions of units. Xilinx has invested into the company as have others.

In the above concept, the first CPU could handle your USB interface and pipeline the USB traffic onto the other 'slaved' CPUs. XMOS has many variations of their devices including a recently announced 32 core unit.

We have designed a SOM based on this new CPU but is on my table to red-line and then move to prototype - ETA is not quite defined yet:

http://www.xcore.com/forum/viewtopic.ph ... lit=softio

If you are able to - can you share your concept ?

USB 2.0 HS (480 Mbps) to XMOS CPU with lots of SDRAM ? Anything else ?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

You can also cascade SliceKits as follows:

Image

That is, to prove a concept, you could as one option:

1) chain your current XCORE-200 USB kit as the first kit (allow it to process your USB traffic)

2) daisy chain onto an XS1 SliceKit which is known to work with the SDRAM slice board you already have at your site - dock the SDRAM module into the XS1 SliceKit and run the SDRAM IP on that target board. You must review how many CPUs are required to operate the SDRAM but you may be able to even support 2 such SDRAM slice boards on the same target board.

The fun will be in managing the data between these assorted modules but not impossible. Much like DMA as you will have a local CPU chatting with the SDRAM. Do review the benchmarks of the SDRAM IP and see if it is a fit for your project.

3) you will have to review how to alter the XN file to announce the interconnect between the CPUs but there are many detailed posts and documentation on this subject

The new XCORE-200 devices are cost reduced and feature rich so ultimately recommend to use these new devices.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

aneves - I am sorry you have had a frustrating experience - I'm engineer working at XMOS who enjoys coming on this forum and talking technical with other XMOS users - so am not the right guy to speak to about commercial issues, but I have raised the issue internally. From where did you buy the kit and which region are you in?

mon2 - thanks for your help too (as always). Keen to hear how you get on with your SDRAM hardware.
Post Reply