+++ Steve Wiseman [04-10-07 11:00 +0100]: > 07/10/2004 09:45:02, "David Bisset" > wrote: > > >Well Samsung obviously have 512M parts in BGA, > > I don't have any in my hand, so I don't quite believe that. It's > plausible, though. > > >Given that: > >a) Most of us have lived happily with 64M (even TCL). > > Partly because TCL haven't released the monster version yet. > There is also the issue of of using Balloon as a compile box, to > stop the need for cross-compilers. Cross-compiling gets easier by the day. It'll always be more complicated than native compilation, but I don't think that not being able to natively compile openoffice on your balloon should be a major part of the design process. We do need enough memeory for the target application. If that app has to be cross-compiled, or natively compiled on a fatter arm system, then so be it (IMHO). Nick has been successfully native-compiling on 64MB machines, which is a bit tight, but shows that it does (currently) work. > Similarly, if Cambridge > computerlab is thinking of letting compsci undergrads near them, > more memory might be handy, if the project wants big datasets > for video or whatever. I can certainly imagine reasonable needs for more than 64Mb. 256Mb as a limit seems adequate, 128 I could probably be persuaded to live with. > >b) No one has owned up to ever having stacked up TSOP's, > something you > >could only do on a few "one offs" given that it wouldn't reflow. > > Certainly. It was never proposed as a mainstream solution. > Imagine the situation where you didn't want to cross-compile. A > couple of development boards get the stacked-RAM treatment, > and production boards get what they need. This does have some utility, but dave's right in saying it rather a minority interest. > >c) You can only work within the technology available at the time > of > >design. > > Yeah. That's why I'm designing in a CPU I don't have, 'preliminary' > NAND devices, a power controller that's disturbing me by its lack > of existence, and we're having this discussion about RAM. About > the only things I'm sure about are the decouplers and resistors... > > >I'd say the choice was obvious go for 4 BGA's. > > Certainly. They're all different sizes, even though they tend to > have the same pinout - the Samsung part isn't the same shape as > either of the Micron offerings. Which one shall I arbitrarily pick, so > that when the manufacturer changes the die size or shape, we're > stuffed, since I've had to pack them in so tightly to allow 4 sites. That is a pain. I was persuaded by dave's 'lets use 4bgas' argument, but if there really is only one source of whichever we pick, that does indeed encourage one to stick to TSOP.... > (Note that the PXA26x only supports 4 banks of up to 64Mbytes > each. And the same for 27x I presume? > 256Mbytes is tops, and that will take 8 16-bit-wide chips. > 32-bit chips aren't commodity, and in TSOP, they're really > annoying to solder. Double-die SDRAMs from Micron are tempting > me again. 2 pairs of > MT48V32M16S2 2.5V 8 Meg x 16 x 4 banks BOTH DIE > would let us fully populate the whole memory space, or any > increment up to that. These are which physical format? > TSOP does have the benefit that Balloons could be shipped > memoryless, and hackers could drop on whatever SDRAM and > NAND devices they fancied / could source. Add to that TSOP54's > universal shape, size and availability, and it's not ruled out yet. It's > certainly the safest option. Agreed, but it does limit production variants to 64Mb - unless the above double-die thing is TSOP... > >If you really want 1G then design and build an expansion board > via the > >LoonBus (it needs a name...) OK so it will be slower, but the > capability > >is there (I assume). > > Tricky. It'd need to present as some kind of swap device - > PXA26x doesn't seem to want to support vast memory spaces. That's a bit sad. This would be a good option for deveopment. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/