Samuel A. Falvo III've been trying to get Micron's cellular RAM chip, as found on the Digilent Nexys-2 (MT45W8MW16 series chip) to function in its documented asynchronous RAM mode, to no success.
It supports reading from the chip with a great deal of ease; but, trying to get the chip to properly respond to memory writes has proven something of an impassible brick wall of a challenge for me.
I'm currently trying to adopt its synchronous mode of operation as I write this log entry. This has several deleterious effects to the Kestrel-3:
- The CPU now requires 3 clock cycles instead of two to access a single half-word of memory. This 50% increase in latency means video and CPU memory accesses can top out only at 8.3 mega-transfers per second. This is 16.6MBps throughput at best, since it's only a 16-bit wide path to memory. This is just enough to support 640x480 16-color displays, which rather sucks (I wanted a 256-color display), but at least it'll be in color.
- The CPU will top out best-case at only 4 MIPS. So, on average, you're going to more likely see 2 MIPS throughput. This is a 300% drop in anticipated performance, putting the computer squarely in the same performance bracket as an Atari 520ST (estimated), provided you use the same video resolutions (e.g., no higher than 640x200 in most cases).
I can reclaim the lost performance when I start to support caching in the CPU. This will allow me to use the PSRAM's "burst" mode, letting me amortize the access time to the chip across 4 or 8 consecutive half-words of memory. However, caches are expensive, complex, and extremely error-prone to implement. I want something, anything, running right now. I don't want to have to wait forever for a computer design that I have know knowledge if it'll work or not.
All in all, I'm not happy about this turn of events. I cannot fathom why the PSRAM chip is incapable of committing writes; I'm not violating any timing that I can see. Normally, you have to work extra hard to get RAM chips to not store spurious data! I am hoping beyond hope that adopting a synchronous memory controller will allow things to work better.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Hey Sam, I also came across http://hamsterworks.co.nz/mediawiki/index.php/SDRAM_Memory_Controller, it might help to compare the two (btw, it's also MIT licensed).
It's used by the ZPUino softcore for instance. That site has a bunch of other FPGA stuff there too which might be of interest. The hardware/logic stuff is beyond me at this point but I do find things that look interesting once in a while :)
Are you sure? yes | no
PSRAM is not SDRAM, and uses a slightly different bus interface. I
have read and write transaction state-machines implemented, but I need
to build a state machine that configures the PSRAM's BCR register before
allowing the CPU to run. I'll get to working on that as soon as I
can. Hopefully, once that's done, it'll "just work." I am not keeping
my hopes up though.
If this fails, then I will have no choice but
to abandon the Nexys-2 as a viable board for future Kestrel
development. That leaves only the myStorm and Terasic DE-1 boards left
as candidates.
Are you sure? yes | no
Ah I see. thanks. I just saw RAM :) In this case does PSRAM stand for pseudo static ram? Came across a chip that gives largish amount of storage and looks like SRAM to a uController but is really a DRAM with it's own refresh circuitry.
Are you sure? yes | no
Yep; PSRAM is Pseudo-Static RAM. The specific product family from Micron is called "CellularRAM". Whatever that means.
Have you used this RAM chip? Was it an asynchronous interface? Assuming yes and yes, did you manage to get it to work for both reads and writes? ;)
Are you sure? yes | no
(replying here as I can't seem to reply to your reply to me)
Alas, no I have not used it, but I recall reading that access had to be completed in a timely manner to allow for the refresh to happen but I can't find where or even which chip/page I was looking at.
Are you sure? yes | no
Also, SDRAM would suffer similar performance losses (for the same reasons) as PSRAM. I desperately need a cache controller if I want to recoup performance.
Are you sure? yes | no
Now I understand why some architectures use the cache RAM for the bootstrap process, e.g. to initialize the RAM interface (I've looked into some MIPS code). I've never implemented anything more complicated than good old DRAMs from scratch - following your progress is interesting.
Are you sure? yes | no
Thomas: I'm fairly convinced that it's a conspiracy by the RAM industry to lock out homebrew hackers and to focus exclusively on Big Silicon for their customers. ;)
Are you sure? yes | no