External memory interface for xcores ?

[Heater]

The are a number of posts around here bemoaning the limited amount of RAM on the Xmos cores.

On the one hand I'm not sure why. After all the Xmos devices are micro-controllers not general purposes CPU's. They are targeted at the "software defined silicon" applications. One is generally hard put to find a micro-controller with 64K of RAM.

On the other hand it does seem to be a shame to limit the capabilities of powerful 32 bit processors with such a tiny work space.

Increasing the amount of RAM and of ROM per core would be great but perhaps eats too much silicon jacking up costs.

So what about being able to configure a set of pins on a core as an external bus interface for RAM and/or FLASH memory from which code can be executed?

I'm imagining that one core of a multi-core device could be configured with external memory and hence able to run a large application or perhaps even Linux or other OS. Mean while the other cores on the device would be performing their normal duty as peripherals and taking care of real-time work.

I'm sure this must have come up elsewhere but I have to ask for myself.

[Folknology]

Hi Heater

It would be worth looking at this thread http://www.xcore.com/forum/viewtopic.php?f=5&t=105 where implementing this is discussed. Even in this case a program is not executed from the external memory because it is not within the address space, rather I/O pins are used to emulate an address bus. It can however be used as a scratch pad memory freeing up internal ram, where larger data processing and video/display storage might be required. It is actually possible to load code indirectly and then execute it but this mode of operation is tricky and less than adequate from a support perspective. Because of the number of pins required it would only make sense using an L1-TQFP128 or XS1-G4-512BGA.

[Heater]

I have seen that thread and such a RAM interface is very desirable for some applications. As you say, good for large data sets, video buffers etc.

But what I was putting up for debate is an optional configuration of pins that would be a real memory bus from which code could be executed. Thus turning a little micro controller in to an full fledged microprocessor.

There is a certain other multi-core micro-controller I use that has similar RAM constraints. In that device all instructions are of a fixed format and 32 bits long. This has resulted in a mode of operation being developed whereby instructions are fetched one at a time from external RAM and executed in a very fast tight loop. This results in a quite speedy execution rate from external RAM. About 4 times slower than running the code directly except for jumps and subroutine calls which require a little extra trickery. There are now two C compilers for that device that generate such "Large Memory Model" code and provide a small execution kernel to run it.

In a way it's like a byte code interpreter or virtual machine except that the codes are in fact the native instructions of the CPU.

I have not looked at the XMOS instruction formats much but I have an inkling that it may be possible to do a similar thing with the XMOS provided the code in external memory is limited to the bit 16 wide instructions. But that would require a special compiler.

[Folknology]

Sorry Rowan my bad for not reading the topic correctly, your right moving forward its worth looking at the problem in a wider context, heres my $0.02 on one of the common applications that trip up on memory.

One of the most common applications that require the extra ram is the use of a graphics display. unlike audio which can be processed on the fly, a graphic display and video require a fixed storage dimension capable of holding the required number of pixels. This is a common requirement and examples of small displays are range from 160 * 120 through 320 * 240 QVGA up to 480*272 and even higher.

In these cases we need the following:
Small (160*120) 19.2K pixels @ 24 bit / 3 bytes pixel ~ 58K
Medium QVGA (320 * 240) 76.8K @ 24 bit / 3 bytes pixel ~ 230K
Large QVGA (480*272) 130.5K @ 24 bit / 3 bytes pixel ~ 2392K

It is fairly clear that even with a small display it will be tough to fit the code and display into internal XMOS RAM on a single core, which all but eliminates single core silicon from these applications. It is possible using channels and multicores but again we are somewhat limited as it would be better for the core that is driving the display to be able to perform more complex manipulations on its data, rather than shunting it backwards and forwards across channels.

Obviously as the display size increases we cannot fit it into a single core, it is then we have to consider the external memory approach.

I think this poses a weakness for the 'softchip' idea, the more chips you have to add to provide basic functionality i.e. memory the less it looks like a 'softchip' the more it looks like electronics rathre than 'revolutionising electronics'. This is made more so be virtually every development board including an external flash part

So if one was to take a birds eye view of the problem and if Xmos were shown that the market for small display based devices was a good place for them to sell silicon into, these issues could at least partially be solved by a couple of internal changes:

1) Increase the internal SDRAM, double it to say 128K
2) Replace the OTP with a reasonable size flash say 32K

This would enable small display based applications to be handled without extra components and would also eliminate the need for external flash chips.

Only for larger display would one need to consider using external memory, the question is how common is this category of application? If a large display is a common requirement then perhaps having the 32 bit port transform into an address bus mode would enable this type of application to be a executed more readily. It would also require new external load instructions to deliver any benefit over the current hacking of external SRAM/SDRAM.

Of course adding the address mode and instructions does enable Xmos to enter market places currently accessible to FPGA/SRAM/SDRAM including high performance DSP applications. So it would vertically improve its reach.

P.S. I have also ignored the use of displays with dedicated controllers, in in those case the problems can be solved in different ways depending on how the application needs to control the VRAM and if it needs to shadow all or only part of it at a time.

How popular is using a display for Xmos applications and what kind of display?

What over types of applications have your worked on that need external memory?

[Heater]

Actually the idea of being able to configure a set of pins as a bus interface also includes the idea that having done so the memory space it addresses also appears in the memory map of the CPU. So no special load/store instructions should be needed. I understand from David May's comments on another thread that the cores are already capable of addressing much larger amounts of memory.

So the scenario is:

1) Configure a bus interface
2) Load the extern RAM with code from FLASH or SPI or whatever
3) Jump to it.

The points you make about memory for graphics are reasonable but guess at some point you end up building a graphics chip not a micro-controller!

What over types of applications have your worked on that need external memory?

Well, professionally everything I have worked on since the mid-nineties has required more space. From aircraft flight controls, to micro-wave base station controllers, to urban traffic controllers.

For a hobby there is creating emulations of old a bit micro-computers than run in modern micro-controllers such as the smallest Z80 CP/M computer in the world http://hackaday.com/2009/12/27/zilog-in-a-matchbox/

[Folknology]

Right gotcha, that would make it much easier

So how wide would you go? a full 32 bit address bus?
don't forget you need a data bus and all the control signals, how many pins are we talking about putting aside? 44,52,60..

[seulater]

The are a number of posts around here bemoaning the limited amount of RAM on the Xmos cores.
On the one hand I'm not sure why. After all the Xmos devices are micro-controllers not general purposes CPU's. They are targeted at the "software defined silicon" applications. One is generally hard put to find a micro-controller with 64K of RAM.

I think that is part of my problem. I was one of those complaining about the limited ram.
When i first saw the site, i saw it was driving LCD, doing Ethernet, controlling LED tiles, motors, bla..bla...bla... in a short time i said to myself "I Gotta get me one of those!!!"
Now that i got it i was like ok, 64k of ram, what the heck am i going to do with that after my code is placed in there. I though ram was ram. and flash, was code. My little ole $9.00 100 MHZ ARM7 part has 96k of ram. and that ram that i can use, not my code shoved in there so i have less.

SO, this is probably the reason why i am so jacked up in the head thinking about it like a replacement for a processor. But...But....But.... its has I/O, a clock, & ram and compiles C / XC so why not ?

ARGGGG, This part is making me crazy ;)

[Berni]

Well we all are saying that 64K is too little and i agree i had problems with it quite a few times. The code seams to eat up most of it so you quickly run out.

I would love to have a external memory bus so i could just stick a few MB ram chip on there and not worry about ram ever again. Even some 8bit PICs have a external memory bus.

[Heater]

seulater, It's not just you. I feel it a well, and there are others. Of course the XMOS can do things the ARM can only dream of.

By the way which ARM are you using that has 96K RAM?. As you see above I have been looking for such a device. Is there a small, cheap dev board for it?

Berni, It was the PIC's with external RAM bus thatgot me thinking about that for XMOS.

Folknology, "So how wide would you go?" There is the question. Wide is more pins and more expensive. If we are thinking small embedded tasks then even just a 16 or 24 address and 8 bit data would do. Although I can see the possibility that a narrow data path for code would bugger up the deterministic timing of the threads.

Actually what about this. Even just a single core XMOS device with pretty much all it's pins used for a wide-wide external bus. For use as a full bore 32 bit "normal" processor with huge RAM and FLASH possibilities. Provide it with two or more XLINKS for hooking up to regular XMOS chips.

In that scenario we have an array of XMOS nodes all programmable from the same XDE, just that one of those nodes is capable of handling the "big stuff" while the others get on with their real-time peripheral functions.

[TonyD]

seulater, It's not just you. I feel it a well, and there are others. Of course the XMOS can do things the ARM can only dream of.

Yes, I agree with you, there are many others myself included who would like to see more memory per core or a option to have external access to more memory

IMO 64K RAM for data memory is adequate but once you use it for program memory as well it can gets used up fast. I would like to see the 8K OTP replaced with lets say a minimum of 128KB Flash memory (if the ic fab process allows for Flash memory), you could then crank it up to 256KB, 512Kb etc.

To put things in context, a typical ARM micro (STM32F103VE) that I use has 64K RAM and 512K Flash (but it would be unfair to compare the versatility of a XS1-L1 to this ARM as it would be like comparing apples to oranges).