Re: Large RAM sizes in embedded systems

On 25 Dec, in article
<1167099288.506816.42290@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
zwsdotcom@xxxxxxxxx "larwe" wrote:
I'd be curious to hear from anyone who has worked on embedded systems
with relatively large amounts of directly-addressable RAM.

My usual cases for that is video memory so organisation is different.

I'm discussing with a colleague/client an application that would work
on a nominally 740GB data set. The nature of the data and the required

Ah the BMF[1] data set scenario that relates to many embedded apps.

processing is such that it's a "must-have" performance improvement to
hold the entire data set in RAM rather than swapping in from some
secondary storage mechanism. It's perfectly acceptable for the machine
to take an entire week to cold-boot. It's not acceptable, once booted,
for it to wait several seconds to page in data from a hard disk :)

Hence I would say my RAM requirement would be speced at 1TB of
error-correcting RAM. The hardware interfaces I would require are
gigabit Ethernet, SATA for the boot media, and a means for connecting
to an ASIC that does all the real processing work. The interface for
that latter is not yet defined, but would quite likely be PCI Express.
All this suggests a PC-style architecture as the way to go.

I'm really not finding much (read: anything) in the way of monolithic
computer modules that can address 1TB. I've found mention of server
clusters that have that much in aggregate, but it's spread across
several computers. OS support for such large RAM sizes also appears to
be problematic, but I could work around this.

Unless you can find something for a 64 bit physical address bus, I doubt
you will find anything that is not limited to the 32bit physical address.

Is anyone else dealing with similar problems? This is strictly a
theoretical investigation for me now - more of a feasibility review
than anything else - but it's quite an intriguing project. Maybe the
right approach is to build a massively parallel engine with identical
modules handling manageable (8GB?) slices of the data set. However this
would be very expensive in terms of power and additional support
circuitry.

Well if you were to use 740GB (or 1TB) data store, perhaps you should
consider how much power that alone will use. How about signal integrity
as the obvious method is to use 1GB (or larger) DIMM modules, which is a
lot of space and track length

Consider this and step back a second, how random access is the data set?
Consider how older systems did bank/page/MMU selection. Could you not
have a means of selecting which 8GB or even 2GB section was selected to
the host memory map?

This way non-selected banks of 8GB (or larger) have their own simple
memory controller to put the memory into standby/auto-refresh, thus
reducing the power requirements. This may also help with signal integrity
reducing errors due to layout restrictions.

What speed due you expect to run this large memory bank?

What ever you do I feel you will need some form of memory controller(s).

Once you have the turnaround time of buffers, memory and track lengths to
consider, PCI-EXpress might be unacheivable. PCI speeds might be easier to
acheive and still be order of magnitude faster than hard drives and the
overheads of dealing with them.

[1] BMF for the times when you start a design before simplification that has
a section that looks like a "Big Mother Fucker of a ...." :-^

--
Paul Carpenter | paul@xxxxxxxxxxxxxxxxxxxxxxxxxxx
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate

.

Quantcast