Suggested DRAM type usage...

[DrMario]

I have been wondering about the type of RAM that can be used with XS1-G4 chip - DDR-II 800MHz, maybe? If not, I can do half the speed bin - DDR-I / II 400MHz.

As the XS1 has screaming fast pipeline, I am more tempted to use the fastest DRAM, XDR-DRAM (3.2GHz bin = x8 - 400MHz), as it would allow almost zero recycle latency (to hide the latency, the RAM transaction has to be really interleaved, the way the original SDRAM [and current DDR-III] was intended). If I can't even use it, it would be kinda bummers (I think I can live with DDR-II).

And, up-front, I am even more aware of the necessity of trace-matching and the usage of decent decoupling capacitors.

So, about the RAM, any idea?

[segher]

None of the RAM types you mention can be directly attached to an xcore, since they
require different voltages from the 3.3V I/O voltage the xcores use.

A single thread cannot read/write more than 400MB/s anyway (assuming 400MHz
clock), and that's without using the data at all -- more realistically you're looking
at 100MB/s, maybe 150MB/s, very very maybe close to 200MB/s.

[lilltroll]

If you use the 32-bit port for DATA, you will have to use the 16-bit for addressing, and the 4 bit port to access each 16-bit page.

Use a 3.3V DDR memory that provides very low CAS and RAS @ 100 MHz, and one that provides burst read and write modes with automatic adresspointer update, so you can R/W a chunk of data without writing a new address for each data access.

But since you have to transfer the data and can use the 64-bits FIFO with 16 bitars port, you may use the 16 bits port for data instead, since you cannot handle above 200 Mbyte/s anyway, which makes the addressing more simple.

But if you are going to use FPGAs as well, you might use one with DDR-X interface, and transfer the data over the links instead.

You can download the designfiles for the XMP-64 and test to add DDR to it. https://www.xmos.com/products/development-kits/xmp-64

[russf]

This may be tangential, but are you all aware of these projects?

http://www.xmoslinkers.org/projects/sdram
http://www.xmos.com/applications/basic-io/sram?ver=all

I'd be interested to know if there is anything that supersedes these designs, or if anyone has any comments about them.

The first project seems very practical, and is specific about memory devices. The second leaves out a lot of detail. I presume there is detailed documentation somewhere else.

I have need for a pretty big fifo. The first design offers 32MB, at a very decent 50MB block-oriented read/write data-rate (I'll be doing block transfers). Of course, yes, my required throughput is much less than half of 50MB/s.

--r.

[russf]

Ah! I see that the SDRAM project has been firmed up and included on the applications page

I also note your SRAM comments here, lilltroll. The performance core-to-core was pretty impressive, I think.

If I don't hear any cries of STOP! from you experts, I'll be laying out the SDRAM design in the next few days.

--r

[lilltroll]

The SRAM only uses a 8 bit data port on the XDK, if I remember correctly, and/or it was something with a 80ns latency on the SRAM. (There exists SRAM nowadays with much less latency that doesn't kill your wallet)

The 16-bit SDRAM therefore gives higher speed at least for burst data transfers compared to my example.

XMOS has gerbers for SDRAM.

[russf]

Thanks for that.

I can use the density. 32MB will be great. And I could still add another of them later, quite easily, by adding a CS_N.

The burst speed is also good. I had played with the idea of using SPI SRAMs, but 32KB per chip is not very dense! And i would have needed a bunch of chip selects. There was a potential advantage with SPI, if each of 4 threads had separate local access to its own memory. But with the burst of SDRAM, and since my data will be blocked after compression anyway, it makes sense to share a single RAM server. I also needed all my data going out to a single destination, so I needed to bring everything to a single point somewhere, in any case. I'll make that RAM look like a big fifo for variable sized blocks that will go over a parallel interface to a PIC32 that's running TCP/IP.

I'm laying out a board with one L1-128 and two L1-64s. The first L1-64 runs a bunch of SPI ADCs, and the second helps with compression, and provides some extra I/O.

[russf]

Some of the reference material such as the schematic from this page:

http://www.xmoslinkers.org/projects/sdr ... ortmap.txt

should probably be added to the formal SDRAM project on the XMOS web page here:

http://www.xmos.com/applications/basic-io/sdram?ver=all

because, on that page there is code, but no clue about how to wire the MICRON SDRAM.

If anyone has any observations about that schematic, I'd love to hear it... just redoing the schematic in kicad.

--r

[dan]

I'm keen to get an SDRAM driver sw component established under the xcore open source project.

As you alluded there are a variety of existing examples, plus xmos has one or two that are not out there yet. It would be good to try and unify these disparate examples, get them up to date along with some basic docs, port maps and gerbers all in one place.

If anyone would like to volunteer to be maintainer for this on xcore github let me know and we'll get a repo established for you right away.

[russf]

Hi Dan,

I can throw my name in this hat. I'm familiar with github, use it constantly, and I have an interest in a good SDRAM design, too.

I can't guarantee to stick with this long term, but I certainly can help for a while, on the basis that if I fall asleep at the switch, someone else should take over.

Let's see if someone else comes forward who can commit, longer term.

I have just done a schematic, and will start layout next week for a board with three L1s, one of which is mostly to drive the SDRAM, as well as do some number-crunching. If there is a way to get any design updates or bug fixes early, then I would definitely take this on, and get the changes into the repo right away.

--r.