What happend with the XMOS DRAM ??

[lilltroll]

If you would compute a large FFT/IFFT
such thing would be nice - external SDRAM



What happened with it ?

(http://www.xmoslinkers.org/projects/sdram/wiki)

[paul]

Not quite sure what you are requesting here? Are you wanting to buy the external SDRAM board?

If so, unfortunately it was not intended to be a product- just for our internal testing and development. The code is still available of course (http://www.xmos.com/applications/memory/sdram)...

[larry]

We have the design files too

[kster59]

I'd like to see a better SDRAM implementation also.

Now that I have used XMOS for about 6months I feel I finally understand thoroughly all the tricks at efficient Xc programming which are unique from C/C++.

I'd like to see an implementation on a L2 chip or better yet an XMOS module with 32mb SDRAM.

I laid out a basic L2 design and used all the pins on core0 for 16bit micron 32mb sdram. All the pins on core1 are available (39 i/o pins).

I would like to make a 40pin DIP module for the remaining pins.

Anyone interested in working together on it?

[lilltroll]

I guess I was mostly a little surprised.
Many threads written by users stated that the available RAM was a large limitation to the XMOS solution,
and in the beginning I was afraid that it would be a future limitation for me.
If I compare the XMOS solution and count the amount of L1 cache (or where you can fetch data within one instruction from RAM), 64-256 kB still isn't a small amount of SRAM.
Many chips has some type/solution of a memory-controller built in to access external DRAM, but accessing DRAM is always done with the penalty of latency - XMOS or not.

So XMOS chips can access DRAM, if you convert one thread to a "memory-controller" on a core, and since I do not see the XMOS solution as something to force an common linux OS onto - I do not necessarily see a large problem that you cannot access a large unified memory space from all cores. A large RAM isn't intended to store 500 sleeping threads as in Windows, instead it would be used for some processing that needs to store large amount of data during the computation as a larger FFT/IFFT !?

So I'm asking if there is any reason to not "promote" the use of external DRAM with XMOS, for users that need for an example 32 MB, since XMOS already tested a HW/SW solution for it !?
Also if you need something in similar to L2 cache, it can be built as external SRAM, which is already present on the XDK.

An Intel Core i7, an ARM or whatever doesn't have a magic solution to guarantee access to large memory spaces without large latency - and therefore you are not guaranteed to complete a task in time. If a branch prediction fails - the wanted data might not be stored in cache - and the operation will be heavily delayed fetching it from DRAM.

Please correct any misunderstandings from my part.


PS. Is it that in general it is so much easier to hide behind an OS from the programmers perspective, and with XMOS we have to deal with those parts as modules running on threads that still might be in a beta stage of development and documentation forcing the programmer to come very close to the scary HW :mrgreen: DS.

[Berni]

Yeah i found my self in need of external ram too. And nasty thing is that the XC-2 doesn't have enough pins of one core on the I/O pins to get a reasonable amount of address lines. Thinking of trying the slow SPI RAM.

Oh and when working with embedded stuff like this i like being close to the hardware as i can see everything thats going on, instead of guessing what the OS is crunching under that hood.

I would love to have some sort of hardware based external memory interface on xmos.

[lilltroll]

Ahaa, of course I'm getting spoiled with the XDK, already having 1 of everything and thereafter 2*64 pins to use for expansion.
An interesting experiment for an economical independent person would be to send an updated version of the XDK to anyone that gets 1024 XCore points without spamming :geek:

[leon_heller]

Given that an XDK costs about 10x the price of an XK-1, shouldn't that be 512x10 or 5120 points? :D

[Folknology]

Hmm this might be slightly off topic but,

I agree with Lilltroll about not needing as much memory because of the way Xmos XS1 is architected, particularly for multicore chips. But there are a few simple things that could help:

1) Ability to be able to dynamically load modules, rather than having to statically load everything into the image. This could make an enormous difference in some case where only some of the functions are needed at any time.

2) Adding mobile features to XC as described by the XOSIG thread, would also go a long way and would likely eradicate the need for any OS. It also lowers the inter core boundaries for memory, and thus can make more effective use of XS1 muticore distributed design.

3) Generous internal fast read memory mapped Flash for storing code. That would mean code run directly from flash, freeing valuable SRAM for other data intensive functions and applications.

4) Larger SRAM options, the L1's are a little tight given their performance compared to high end MCUs.

5) All I/O pins should have any function (1,4/4l,8,16,32bit), much like an FPGA including conversion to memory mapped address buses.


Obviously it gets tougher as one moves down that wish list!!

regards
Al