SDRAM Driver

David Betz

Is there any chance that this thread could get back on the topic of Chip's SDRAM driver? I keep seeing new messages here hoping that they are updates on the driver but I only find discussions about video quality. Would it be possible to move the video discussion to another thread?

Thanks,
David

potatohead

Yes. All done. Very good call.

evanh

To summarise, with respect to bandwidth requirements, which is why the discussion over interlace started, interlace provides best bang for the bandwidth when using a TV. Including HDTVs.

Modern LCD computer monitors presumably don't support interlaced encoding at all given the LCD panel itself is incapable of handling interlace without deinterlacing hardware. Therefore, with a minimum vertical sync of 50 Hz and the interlaced derived progressive encoding out of the picture, that probably leaves only sequential encoding with it's full bandwidth requirements.

That makes a distinct division between TVs and monitors if you want to save on bandwidth.

Bill Henning

I'd like to see a 1080i driver, but 1080i and 1080p30 should use exactly the same memory bandwidth - assuming the given tv/monitor supports 1080p30

evanh wrote: »

To summarise, with respect to bandwidth requirements, which is why the discussion over interlace started, interlace provides best bang for the bandwidth when using a TV. Including HDTVs.

Modern LCD computer monitors presumably don't support interlaced encoding at all given the LCD panel itself is incapable of handling interlace without deinterlacing hardware. Therefore, with a minimum vertical sync of 50 Hz and the interlaced derived progressive encoding out of the picture, that probably leaves only sequential encoding with it's full bandwidth requirements.

That makes a distinct division between TVs and monitors if you want to save on bandwidth.

evanh

Bill Henning wrote: »

I'd like to see a 1080i driver, but 1080i and 1080p30 should use exactly the same memory bandwidth - assuming the given tv/monitor supports 1080p30

Yep, 1080i60 has same bandwidth. And I'd like to see/hear of comparisons done between them for impressions on various TVs. And also see if any modern LCD computer monitor can handle theses modes.

Ale

I have a couple of questions regarding driving the SDRAM (I am using the board described here http://forums.parallax.com/showthread.php/119689-A-new-dimension-in-Propeller-marriages-pPropFPGA/page1.
I am trying to make the SDRAM work, but I do not know what does not yet work, writing or reading...
Symptom it reads garbage but constant garbage !,
The question is, should I negate nCS after a command ? because the Micron datasheet seems to imply that it should be kept asserted (LOW) but the ICSI datasheet clearly shows it negated when data is being transferred. Does it make a difference ?, I mean Chip toggles it in his driver (and it works!!!)

ICSI datasheet: http://pdf1.alldatasheet.com/datasheet-pdf/view/116589/ICSI/IC42S32400.html
Micron datasheet: www.micron.com/parts/dram/sdram/mt48lc16m16a2bg-75?pc={428A5CC9-2A78-447E-939B-6F3A40D538C6}

Thanks in advance

Ale

I have a couple of questions regarding driving the SDRAM (I am using the board described here http://forums.parallax.com/showthread.php/119689-A-new-dimension-in-Propeller-marriages-pPropFPGA/page1.
I am trying to make the SDRAM work, but I do not know what does not yet work, writing or reading...
Symptom it reads garbage but constant garbage !,
The question is, should I negate nCS after a command ? because the Micron datasheet seems to imply that it should be kept asserted (LOW) but the ICSI datasheet clearly shows it negated when data is being transferred. Does it make a difference ?, I mean Chip toggles it in his driver (and it works!!!)

ICSI datasheet: http://pdf1.alldatasheet.com/datasheet-pdf/view/116589/ICSI/IC42S32400.html
Micron datasheet: www.micron.com/parts/dram/sdram/mt48lc16m16a2bg-75?pc={428A5CC9-2A78-447E-939B-6F3A40D538C6}

Thanks in advance

Edit: I changed the slew-rate of the CS/RAS/CAS/WE pins to fast and it seems to work now... sort of...
Now i have to figure it out why a counter counts down when it is suposed to count up....

Edit2: it still does not work reliably , setup times look good...

cgracey

Ale wrote: »

I have a couple of questions regarding driving the SDRAM (I am using the board described here http://forums.parallax.com/showthread.php/119689-A-new-dimension-in-Propeller-marriages-pPropFPGA/page1.
I am trying to make the SDRAM work, but I do not know what does not yet work, writing or reading...
Symptom it reads garbage but constant garbage !,
The question is, should I negate nCS after a command ? because the Micron datasheet seems to imply that it should be kept asserted (LOW) but the ICSI datasheet clearly shows it negated when data is being transferred. Does it make a difference ?, I mean Chip toggles it in his driver (and it works!!!)

ICSI datasheet: http://pdf1.alldatasheet.com/datasheet-pdf/view/116589/ICSI/IC42S32400.html
Micron datasheet: www.micron.com/parts/dram/sdram/mt48lc16m16a2bg-75?pc={428A5CC9-2A78-447E-939B-6F3A40D538C6}

Thanks in advance

For most commands, you will need to drive CS high on the clock after driving it low, so that only one command is registered by the SDRAM.

Ale

Thanks chip!
After days of testing it still doesn't seem to work right .I'll clock the SDRAM at 25 MHz and see if that helps. It writes, that I can see but reading from multiple pages seem to show strage data, I mean powering it off doesn't seem to erase the data that fast.... or maybe power is leaking from somewhere, jtag, logic analyzer...

cgracey

Ale wrote: »

Thanks chip!
After days of testing it still doesn't seem to work right .I'll clock the SDRAM at 25 MHz and see if that helps. It writes, that I can see but reading from multiple pages seem to show strage data, I mean powering it off doesn't seem to erase the data that fast.... or maybe power is leaking from somewhere, jtag, logic analyzer...

I found it kind of difficult to get working. Once it was right, it all made sense, and I could go about improving it. Getting there was hard, though.

David Betz

I finally got around to trying Chip's SDRAM driver from C. Here is a really boring test program to verify that the C interface is working. This is using an almost unmodified version of Chip's driver. The only thing I changed was to remove the test code from the start so the first location in the SDRAM_Driver.obj file is the first instruction of the driver itself.

#include <stdio.h>
#include <stdint.h>
#include <propeller.h>

#define LEN_16      0x00000001
#define LEN_32      0x00000002
#define LEN_64      0x00000003
#define LEN_128     0x00000004
#define LEN_256     0x00000005
#define LEN_512     0x00000006
#define LEN_1024    0x00000007

#define READ        0x00000000
#define WRITE       0x00000008

#define MEMORY_SIZE             (16 * 1024 * 1024)
#define BLOCK_SIZE              64
#define BLOCK_SIZE_IN_LONGS     (BLOCK_SIZE / sizeof(uint32_t))
#define ALIGN                   16

int main (int argc,  char* argv[])
{
    extern char binary_SDRAM_Driver_obj_start[];
    volatile uint32_t params[3] = { 0, 0, 8 };
    uint8_t buffer[BLOCK_SIZE + ALIGN];
    uint32_t *bufferp = (uint32_t *)(((uint32_t)buffer + ALIGN) & ~(ALIGN - 1));
    uint32_t addr, data, data_start;
    int count, i;
    
    cognew(binary_SDRAM_Driver_obj_start, (void *)params);
    
    for (data = count = 0; ; ++count) {
    
        data_start = data;
        printf("writing %08x %d\n", data, count);
        for (addr = 0; addr < MEMORY_SIZE; addr += BLOCK_SIZE) {
    
            for (i = 0; i < BLOCK_SIZE_IN_LONGS; ++i)
                bufferp[i] = data++;
            
            params[1] = addr;
            params[0] = (uint32_t)bufferp | LEN_64 | WRITE;
            while (params[0])
                ;
        }
        
        data = data_start;
        printf("reading %08x %d\n", data,count);
        for (addr = 0; addr < MEMORY_SIZE; addr += BLOCK_SIZE) {
            
            params[1] = addr;
            params[0] = (uint32_t)bufferp | LEN_64 | READ;
            while (params[0])
                ;
    
            for (i = 0; i < BLOCK_SIZE_IN_LONGS; ++i)
                if (bufferp[i] != data++)
                    printf("%08x %08x %08x\n", addr, data - 1, bufferp[i]);
        }
    }

    return 0;
}

Here is the Makefile required to build this test:

CC = propeller-elf-gcc
OBJCOPY = propeller-elf-objcopy

CFLAGS = -mlmm -mp2 -Os

TARGET = sdramtest.elf

OBJS = sdramtest.o SDRAM_Driver_firmware.o

all:	sdramtest.elf

$(TARGET):	$(OBJS)
	$(CC) $(CFLAGS) -o $@ $(OBJS)

%.o:	%.c
	$(CC) $(CFLAGS) -c -o $@ $<

%_firmware.o: %.obj
	$(OBJCOPY) -I binary -B propeller -O $(CC) $< $@

run:	$(TARGET)
	propeller-load -b de2-115 $(TARGET) -r -t

clean:
	$(RM) $(TARGET) $(OBJS)

The output should look something like this:

david-betzs-macbook-pro:sdramtest dbetz$ make run
propeller-load -b de2-115 sdramtest.elf -r -t
Propeller Version 32 on /dev/cu.usbserial-A800f7XO
...............
[ Entering terminal mode. Type ESC or Control-C to exit. ]
writing 00000000 0
reading 00000000 0
writing 00400000 1
reading 00400000 1
writing 00800000 2
reading 00800000 2