Samuel A. Falvo IIAfter researching the different kinds of memories one has available to them on different FPGA boards, in conjunction with how utterly difficult it is to actually use some of these memories, I've decided to remove the 8MB of RAM specification for the Kestrel-3. Instead, I'm now going to set the RAM requirement to 256KB static RAM minimum.
This is a breaking change, and will require alteration to the software emulator, eForth, and the documentation. However, I cannot see any way around this change.
For main-line storage, virtually all FPGA boards I've looked at tends to offer either 1MB to 16MB of static(-like) RAM OR 16MB to 64MB of (sometimes DDR) SDRAM plus 512KB of static RAM. Since SDRAM represents clinical levels of insanity to initialize, to the point where hardware controllers literally just punt completely on the problem and modern CPUs must resort to such insanity as using cache RAM as scratch-pad RAM, I've decided it's best to specify a minimum amount of scratch-pad for use in bringing up the remainder of the system instead.
This means that eForth will have access to only 256KB of RAM minimum, not 16MB as it currently does in the emulator. Moreover, MGIA/CGIA's default frame buffer will be located in the 256KB block guaranteed to exist. This allows the system software to continue to display diagnostics as required. (Exception: for BlackIce boards, no video output will exist, and all I/O must occur through PMOD interfaces of some kind.)
Speaking of system firmware, the capacity for that will also need to drop as well, to something that will actually fit in the BlackIce project. However, I'll make a separate announcement on this later, once I have more data about what can and cannot fit. However, at least its location in the address space will remain where it's at.
This change should be trivially supported by most FPGA boards, since most offer 512KB to 1MB of static RAM of various speeds. Nexys-2 can be configured to offer up to 16MB, since its cellular RAM chip is of that capacity. However, to gain more capacity, most FPGA boards will need to run some software to train the SDRAM interface before using it. (Or, at least, have the benefit of a suitably intelligent hardware controller to do it for the system software.)
I'll be implementing these changes, probably about the same time as I switch the 53000 over to booting and running in user-mode instead of machine-mode, since that too is a breaking change. Might as well break everything all at once!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
I just came across http://codehackcreate.com/archives/444, maybe it could be an option.. (License is MIT) (Same person who did the F18A VDP clone)
Are you sure? yes | no
Good find! I'm impressed with the sheer amount of code involved; it's very intimidating. And, hopefully, it can be ported successfully to the cellular RAM that Nexys 2 board and the SDRAM that the Terasic DE-1 use with relative ease. I'll need to study the code carefully. Thanks!!
Are you sure? yes | no
I am sure you have looked at some alternatives, probably scrapped them for good reasons. I stumbled on this and wonder if something like this could work:https://opencores.org/project,hpdmc
Are you sure? yes | no
The license is a show-stopper for me, since GPL is not compatible with MPL. I'd have to relicense the entire computer design to use it. But, maybe I can learn from it and implement my own some day.
Are you sure? yes | no
"SDRAM represents clinical levels of insanity to initialize," That explains a lot :)
Are you sure? yes | no
What is it with the electronics industry? SD cards are the same way -- utter *insanity* to initialize. But once SD is up and running, it's truly a breeze to work with. I'm hoping SDRAM is similar; once the controllers are trained against the RAM they're talking to, and CAS latencies are set, then using it should be almost transparent. :)
Are you sure? yes | no
Indeed, not that difficult... at least SDRAM (rather'n DDR++, I haven't worked with those). Just don't forget to refresh! Well, and opening/closing rows is a tad annoying when compared to the typical SRAM interface.
Are you sure? yes | no
Tracking issue:
https://github.com/KestrelComputer/kestrel/issues/253
Are you sure? yes | no
You raise serious and important questions here...
For now I just avoid using DRAM.
Are you sure? yes | no
Well, a 64-bit CPU is kind of hampered a bit with such small quantities
of RAM. I would very much like to have more than a stock Amiga 1000's
compliment of memory. ;)
Are you sure? yes | no
it's always been my impression that doing the CPU core was the easy task. Making the whole thing work and "fly" is really hard...
Good luck :-)
Are you sure? yes | no