XCore Exchange

Hi Folks,
I don't want to reinvent the wheel, therefore I would you like to discuss the topic first here. Probably, it would be nice to find participate partners too for specification/design/implementation steps of the subject.

I spent one month to implement a gui+view/controller framework plus the required busines logic for some kind of "hard coded" system. There are some limitations, what I have to keep in mind during the refactoring of the whole system. The most important factor is the 64k memory limit. There are several technics, which are already published. I did some study to figure out what is possible, and what would be reasonable. Lets talk about!

Imagine a system-design, where we have more than one xmos chips (tiles), somewhere in the system we have an SDRAM, spare SPI flash, and several "block / stream devices" (throughput demand) and several modest peripherals.

It would be nice to have a common virtual address space, where pages/blocks can be allocated for the different external memories (compile time). Each tile would have an allocator (or cache) table, which stores informations about the local storage, and the origins, actual state. The local storage can be a buffer pool, where several pages can be loaded partially (from the specific external ram/flash memory or from other tiles shared memory). Each tile will have an event handler, which one catch ET_LOAD_STORE exception. Exception handler will check the hit in the local cache table, then if address is paged to local memory returns by the internal ram address, or loads up from the external source if it is not loaded actually. (this is just a quick explanation) So, user code can use 32bits virtual address simply to reach more than 64k.

There are already some examples/studies, possible can be part of this system. Namely: sc_memory_extender, lib_sdram, lib_flash, etc. I've just took a look on these codes, and wondering if how would be the best to build up a new system based on this idea...

I see you've already found sc_memory_extender, which contains code for handling a ET_LOAD_STORE exception. I wrote this code a while back, and I'd be happy to answer questions about it.

You might also want to take a look at the following git repo:

https://github.com/stevekerrison/sc_memkernel

This repo also has code for handling a ET_LOAD_STORE exceptions (although, being a proof of concept, it looks like doesn't handle 8bit or 16bit accesses). The exceptions are translated to remote memory accesses requests that are handled by server tasks running on each tile.

Hi,
Richard thank you! The answer in Q&A was lifesaver :).
I upload an initial version, which is based on the sc_memory_extender codes.
I need a lil bit more time to understand what the sc_memkernel does. :)

What I actually uploaded to github, can access to remote tiles ram and there is some placeholder for further features...
https://github.com/bfarago/xmos_virtual_address

update:
- preliminary memory mapped file backend added.

update2: SDRAM handler added too. Main problems are:
- movable ptr required by lib_sdram, there is an ET_ECALL exception : error: movable pointer `buffer' does not point to its initial object when going out of scope... (OK)

- handler.S calls 8bits version of data transfer function when indexed array syntax used (p=x) rather than 32bit one. Probably the lookup table is wrong?

- debugger gave wrong values occassionally. (lack of stack? bug?)

I took another look at memory extender code. I noticed a bug in the kernel stack allocation which could have caused memory corruption - I've pushed a fix for this. I also extended the example app to try all combinations of load / store instruction. The app now hits the same issue you ran into, i.e. when a STW_l3r instruction causes an exception the st8 method is called instead of the stw method. I'll see if I can figure out what is going wrong.

richard wrote:The app now hits the same issue you ran into, i.e. when a STW_l3r instruction causes an exception the st8 method is called instead of the stw method. I'll see if I can figure out what is going wrong.

There was an error in one of the lookup tables - I think it should be fixed now.

Richard, thanks for the help! Indexed load/store works fine now. Hurray!
I was updated my github's repo too. (xmos_virtual_address)
-added the fix
-some workaround added for lib_sdram required movable ptr support. (it was a bit tricky)

So, the test code for sdram pager started to working right now.
But still I would like to clarify the page swapping mechanism, interfaces, movable ptr handling, etc...