--- Quote Start ---
originally posted by kenland+jul 21 2004, 03:23 pm--><div class='quotetop'>quote (kenland @ jul 21 2004, 03:23 pm)</div>
--- quote start ---
will your instruction source require all of this ram or could you get away with say a 16mb chip on board for code and use the sodimm for data buffer?
that's kind of what we did with our last coldfire board. it has enough sram on board to run, but detects and uses whatever is in the edo simm slot. so even if the stick goes bad the board still functions.[/b]
--- quote end ---
we thought of that, but the goal for using an sodimm is to simplify things by having just one memory bank (hence, one memory bus). in our case, memory failure is pretty much system failure, so there's no benefit there, either. we may have the fatal exception vectors point to internal memory, where it will report the error to the outside world and then hit an infinite loop.
we're doing what you're talking about on a ti dsp board, which has internal and external ram banks. the code lives internally along with data/bss/stack/heap, and we have our own memory allocator that deals with the external memory for bulk use.
<!--quotebegin-kenland@Jul 21 2004, 03:23 PM
what mechanism if any (no mmu) in the nios stops you from setting a pointer to any address you want and writing or reading? (as long as it exists) --- Quote End ---
You have to tell the SDRAM interface SOPC component what the maximum size is so it generates the proper addressing hardware and I/O pins. But if the software side assumes that you always have that much memory, there will be trouble. All I need is a mechanism to tell the software side to use only a minimum amount of the RAM, then I can manage the rest myself, but it would be easier if I could just tell the thing to move the top of the heap up and just use malloc/free. There may be a mechanism to do this; I haven't gotten that far yet.