SDRAM on XGC/Xshell board or LS1 device

Non-technical related questions should go here.
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Re: SDRAM on XGC/Xshell board or LS1 device

Postby Heater » Wed Jan 27, 2010 9:28 am

OK points taken about the use of an FPGA over an xcore.

However it seems to me that if you are squeezing the access to RAM down a channel over an external link to an FPGA the speed advantages of the FPGA over an xcore is no longer the significant bottle neck. So again would it not be preferable to use an xcore instead of an FPGA and take the slight speed hit.

This would have benefits of power saving, cost saving, common programming model, reduced inventory and possibly some spare xcores (on the RAM driver).

Point also taken about nurturing the skills of writing distributed applications. My fist steps with that on the xcores are to get a simple 6809 emulator running in 4 cores. Sharing RAM through channels so as to make up the 64K required for the emulated address space.

Still, what have people been doing in the embedded space? Back in the early 80's I worked on a machine control system that used 6 times 8085 processors. It need so many a) To have enough space for program and data and b) To get the speed required to keep up with the machine.

So parallel distributed processing has always been part of the job for me. I was always drooling over the Transputer as a perfect fit for that kind of problem. Now we have Xmos.
jhrose
Active Member
Posts: 40
Joined: Mon Dec 14, 2009 11:18 am

Postby jhrose » Wed Jan 27, 2010 11:07 am

Hei,
would it not be preferable to use an xcore instead of an FPGA and take the slight speed hit
Your suggestion is good for numerous applications, for example choosing an xcore as an alternative to a high-end PIC, and would suit high-volume low-cost designs. And having a library for xcores which supports functions like those you suggested earlier in this thread would be nice.

However, anything with a CPU-addressable EMIF, like an ARM, which can run code off-chip scales up to a different class. I imagine (re-)using an FPGA-based design as a memory controller should make it easier to scale up for larger applications that embed xcores by making software/firmware changes (not to mention higher speed SDRAMs). FPGA seems better-suited for lower-volume designs or ones with a host (operating system) interface; or is there a small low-power FPGA that would serve?

There is a halfway-house that dispenses with the FPGA and instead uses an Xlink to a host processor with lots of memory. But this also does not make it easy to copy code around. Hmm - do you think someone could invent a self-refreshing SDRAM that exposes an Xlink control and data interface?
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Postby Heater » Wed Jan 27, 2010 11:22 am

Actually I'm not sure what you are driving at here.

I imagine there are requirements for systems requiring a nice big memory space in which to run a traditional OS complete with all the services it can provide. Networking, user interface, file systems etc etc. Lets say based on ARM. Then that communicates with an Xmos device or a "farm" of Xmos devices that take care of real-time control tasks. Many a time I have worked on systems like that.

In that scenario what is needed is a an Xlink from the ARM to the "farm". Well that can probably be done by using the pins of one xcore as a bus interface, as a peripheral, the xcore is then just a "bus to xlink" bridge.
do you think someone could invent a self-refreshing SDRAM that exposes an Xlink control and data interface
Sounds like a Pseudo Static RAM (PSRAM) with an Xlink. Excellent idea. As it stands we can make that with PSRAM chips and an xcore to drive it providing the xlink on the other side.

I think in the back of my mind is the idea that if xcores need FPGAs for support then there is something not quite working out with the "Software Defined Silicon" idea of the xcores.
User avatar
TonyD
XCore Addict
Posts: 234
Joined: Thu Dec 10, 2009 11:11 pm
Location: Newcastle, UK

Postby TonyD » Wed Jan 27, 2010 12:02 pm

Heater wrote:I'm a bit out of touch with current memory technology but isn't it so that accessing FLASH slower than accessing from RAM. This would somewhat upset the deterministic timing of the xcores. As would having an external bus interface.
Yes slow Flash could be a problem but could possibly be designed around, for example the NXP LPC210x ARM7's avoid the problem of slow Flash by using 128-bit wide memory architecture for their Flash and ran at 72MHz. NXP's Cortex-M3 devices run at up to 100MHz but I'm not sure how well this approach could be scaled up to 400MHz of the XS1.
Heater wrote: SPI RAMs are nice but of course much slower.

An external parallel RAM is what I'm looking at for getting a Motorola 6809 emulation running on xcores. even just a small SRAM or PSRAM would do.
True the SPI RAM's are much slower but their SPI interface can be clocked at up to 20MHz which could be quick enough for certain applications.

Interfacing a smallish SRAM (128K or 512kx8) is doable even on the XS1 L1 64 but it would depend on how many I/O you need for your main application.

Heater wrote:... it would be great to be able to execute some kind of byte code from external RAM with a small virtual machine in the xcore. This would allow for those "large" programs that do not need to be speed or real-time critical.

Anyone know of such a language/execution system that would fit in the 64K available in the xcore? And no, not Forth please. Something a bit more C or Pascal like.
A small byte code interpreter / virtual machine would be a great project to have. I remember using the Intel 8051 BASIC chips for many "quick hacks", so would love to see something similar on Xmos. Something small that could fit into the 8K OTP with a SD card boot loader would be awesome. I researched JavaCard, a stripped down Java implementation for smart cards back in the late 90's and their VM fitted into a small memory space. I'm not sure how Java evolved since then but I guess there will many small implementations of Java out there.
Last edited by TonyD on Wed Jan 27, 2010 12:57 pm, edited 1 time in total.
jhrose
Active Member
Posts: 40
Joined: Mon Dec 14, 2009 11:18 am

Postby jhrose » Wed Jan 27, 2010 12:46 pm

Heater wrote:
I'm not sure what you are driving at here
I'm driving at scalability in the FPGA - my context is XOSS at http://www.xcore.com/forum/download/file.php?id=16. And a controller and farm like you describe for a hosted solution.
an Xlink from the ARM to the "farm". Well that can probably be done by using the pins of one xcore as a bus interface
Perhaps even simpler than a bus-to-xlink bridge is use an XC service over an xlink (as in chapter 3.7 of the programming XC book). At the controller end Ali/Paul have provided VHDL for an Xlink, and you could use GPIO lines on a processor like ARM with an Xlink device driver software.
I think in the back of my mind is the idea that if xcores need FPGAs for support then there is something not quite working out with the "Software Defined Silicon" idea of the xcores.
Another view is that xcores are good at some stuff and FPGAs are good at other stuff, so you can use them both to advantage in a system design.
User avatar
DrFingersSchaefer
Experienced Member
Posts: 65
Joined: Fri Dec 18, 2009 1:27 pm
Location: The Interzone

Postby DrFingersSchaefer » Thu Jan 28, 2010 12:20 pm

Having and embedded language/os and development system that can fit in 8k (or at least a usable kernel) is what Forth is all about.
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

Postby kster59 » Fri Jan 29, 2010 11:22 am

The main problem for me is the SDRAM driver is not trivial to use. It's not as simple as hooking up pins up in an optimal way and just writing to it. Configuring the VHDL DDR Wishbone bus on my Xilinx chip only took a few minutes to read the docs and use it.

It's been a while since I looked at it but from what I remember, the SDRAM random driver took 3 threads, 2 or 3 clock blocks and the driver still only runs at 25mhz (compared to 150mhz on a dedicated mmu) and you need to write code to do the refresh manually. Basically you're dedicating the entire core just to do the SDRAM function which is a few hundred logic block units in an FPGA - not to mention the time I spent trying to figure out how to make it work with other stuff on the L1-128.

On my $5 ARM, when I want to use SDRAM with the ARM, I call "Sdram_Init()" then "pMyRam=SdramAlloc(size)". That's it and I can write to it like a regular C array. I also replaced the FTDI usb chip, 10/100 ethernet phy and lcd touchscreen driver at the same time. To use any of those functions, you need special purpose chips on the XMOS (usb phy to capture USB clock, ethernet phy, a/d). On the ARM, I connect the USBD+ directly to a pin and that's it.

Just need to port the XLINK to ARM and I will hang the xmos device off it to do special timings on my next design. I do like the XMOS a lot and I do agree it's way either to write some fast timing but for onboard peripherals, it's much easier/cheaper/faster just to use an FPGA or ARM.

SDRAM is very important to many non-trivial applications. 32MB of SDRAM at 150mhz is around $5 in qty 10 can't be compared with 25mhz 1 bit SPI ram with 32kB capacity.

PSRAM is available only in BGA last time I looked which adds $500 to a prototype PCB/assembly. It is also substantially more expensive than plain SDRAM chips which are made in quantities of hundreds of millions.
User avatar
shawn
XCore Addict
Posts: 238
Joined: Thu Dec 17, 2009 5:15 am

Postby shawn » Fri Feb 12, 2010 7:05 am

This thead's interesting. memory as carrot.
Memory can be very inexpensive, and you
could be spending to much resource trying
to get at it. I remeber back in the sweet good
old days someone would take a $10,000.00
FPGA and the set a $50.00 memery chip next
to it. It didn't make alot of sence to me, but they
needed that RAM, I guess. back then I also
realized you could buy a gig of dram for say $100,
so here's a billion transistors and only 64 transitors
would really be doing any work. Its nice for resource but
the power issue was 64:billion. It also requires more
system services, so the bigger you get the more heat.
The Xmos dosn't have the notion of external memory.
Therefore would we'll code more wise. We have been
so conditioned about memory we forget the machines
that had so litttle. Fpga's are the natural pinnicle of ex-
otic memory. Fpga's are a subect in and of themselfs.
The Xmos is SDS therefore Fpga's are a natural fit.
Fpga's come in many flavors, most don't qualify as a
natural match for the Xmos. Power, price, performance
are the issues. Not to mention, tools, learning curve,
making ones choice more duanting. Fpga's are a trip,
the heroin of the industry, and so be cafefull, in that, so
many service have hooks, lots of golden screwdrivers.

Who is online

Users browsing this forum: No registered users and 0 guests