Found some SRAM in the toolbox - useful with a prop?
soshimo
Posts: 215
I was digging around for something unrelated and found these chips at the bottom of my drawer: DS1265W.
It looks like I might have to load the address in two cycles - using some kind of latch - either that or I will have to use up 18 pins on the prop just for the address. I'm thinking I could have two external registers - one the page register, the second one the base address register. Alternatively I could use a serial to parallel shift register, but that would make memory access times 18x the clock cycle + the actual timing for the operation.
Is there any precedence? Is it even worth bothering?
TIA
It looks like I might have to load the address in two cycles - using some kind of latch - either that or I will have to use up 18 pins on the prop just for the address. I'm thinking I could have two external registers - one the page register, the second one the base address register. Alternatively I could use a serial to parallel shift register, but that would make memory access times 18x the clock cycle + the actual timing for the operation.
Is there any precedence? Is it even worth bothering?
TIA
Comments
Yes, lots - you should read the various threads about RamBlade, DracBlade, Morpheus, TriBladeProp, Hybrid/Hydra (using HX512 SRAM card).
All these have external SRAM, and all are supported by the Catalina C compiler, allowing C programs up to 16Mb to be executed from external SRAM connected via a parallel interface. You could also look at the Catalina documentation - see the compiler's XMM (eXternal Memory Model) mode.
The speed depends very much on how many pins you want to dedicate to your SRAM interface. It is not exceptional unless you are willing to sacrifice a lot of pins - using a RamBlade I have Catalina executing on a single cog at about the speed of a MicroVax 1. That takes (from memory) about 24 pins. The DracBlade takes about 8 pins and executes about 1/3 the speed.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 7/19/2010 5:29:15 AM GMT
Oh yes. As RossH says.
The Hydra game system has a RAM card but is designed for fast block access with CPLD containing an address counter. It will do byte by byte access (to the first 64K only I believe) but is is slow and clumsy to use that way. Expensive.
The TriBlade and RAM blade cards are from Cluso here. Originally designed for use with software emulating other micros like Z80, 6502, 6809 which need 64K or more of RAM dedicated to the "guest" CPU. Cluso's designs are built for speed of byte wide access. The emulators run on those boards at about the speed of the original chips.
I have a TriBlade. It's great. Three Propellers, one with most pins dedicated to fast 1MB ram access and SD card. One with all the bits of a Demo Board for video and keyboard etc. One mostly has free pins. They can all be linked via serial connection.
I have Dr_Acular's "DracBlade" board. Yet to be built up. Also designed for Z80 emulator. He uses your approach with latches. Not so fast but leaves pins free so the board has video, keyboard, SD card etc from just one Prop.
No idea about Bill Henning's Morpheus boards yet. But as Bill has made VMCog as a memory management unit and cache kind of system my ZOG byte code interpreter will run C++ code on all these cards, and others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Not quite true regarding the Hydra and Hybrid - the HX512 can be upgraded (using CPLD firmware created by epmoyer) to allow random access to all 512k. The firmware is included with Catalina, but you have to buy/build the CPLD programming cable yourself (instructions are included with the HX512). Due to some clever "auto address increment" functionality in the HX512, the final speed is not too bad - not too far behind the RamBlade.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Presumably by "not too far behind RamBlade" speeds you mean for sequential block access using "auto address increment". Does Catalina use it that way?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes. The autoincrement mode is used (for example) when reading or writing each of the 4 bytes of a long. This saves quite a lot of messing about. Also, when executing using the SMALL XMM mode (where only the code is in XMM) the only time you usually need to update the address latch is when the program executes a Jump instruction. It's quite nifty.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
There are 3 available and tested firmwares: Andre's original, Empmoyer's and the lesser known, but maybe the most advanced from Kuroneko.
All three are AFAIK driver compatible when used whithin the lower 64KB block, and the autoincrement can be disabled resulting in a random access not dissimilar from the one used on DracBlade.
@Rossh
Just a quick note to report one experiment I made some time ago with the HX512 card, sorry if it's not fully on-topic.
In the original drivers for Hydra, it's not clear to me why Andre decided to do "byte walking" to the desired address over the lower 64KB, resulting in a worst case access of approx 460000 HX clocks (!).
I tried a simple mod to the driver, to use "page walking" to reach any address in 512K, resulting in approx 3600 HX clocks worst case.
e.g. setting lower address to 255, and then doing a dummy read, so you "walk" a 256B page in two clocks.
While still so high to prohibit pure random access (not really random at all since it depends on address!), I think it's somewhat interesting for page burst applications (including VMCog).
To have a more balanced test in addition to worst case I used the following method:
- pre-generate 4096 random start addresses, saved in array to keep random generation out of the loop
- calculate SPIN overhead by calling dummy methods (including mailbox)
- from every address read or write one 256B page
- calculate and average totals
The results were interesting and very consistent over multiple runs: normalized vs Empmoyer's firmware, the modded driver + original firmware combination scored "only" 5 times slower, while the original driver + original firmware combo was about 400 times slower.
Maybe it's not all lost for HX512 owners who cannot upgrade the firmware ?
Had a look at DS1265W datasheet (and price... ouch!).
Apart from the internal battery backup, it looks like a normal parallel SRAM, just a little slow in access time.
I think it's well worth the effort, considering the memory size that's twice of what is commonly used in other prop XMM designs.
I suggest you to use latches, reproducing the DracBlade layout, since it's one of the better supported platforms.
Also many other platforms have no spare pins to drive for A19, as they were tightly designed to obtain maximum speed, the DracBlade IIRC should have some spare pins on higher order address latch.
The latch setup plus the access op will satisfy the 100ns cycle time, just pay attention also at the write signal (75ns) and data setup times (40ns), they are a little high and may require inserting some NOPs in DracBlade software routines.
Alessandro
@Alessandro Good information there - esp. regarding the latency times of the memory (where and how to compensate for it). I think I got these chips from Maxim as a free eval - I know I wouldn't have paid that much for them. That being said, I'm not sure the extra memory over and above the HX512 is worth the cost. It being slow is also a factor. I suppose having the battery backup is nice - it gives a 10 year retention time on data - so they can actually be used like eeproms (if you plan on accessing and refreshing the data at least once a decade). There is no limit on writes, so that's one advantage over eeproms. Still trying to decide if jumping down this rabbit hole is even worth it. I may put it on the back burner and concentrate on my original project. Thanks for the great information.
@ Everyone
Thanks for getting back to me and pointing out some great places to start. I think I will take the DracBlade approach and use address latching. I just ordered some octal latches so we'll see where that goes. Thanks again!
Thanks for the update. I found epmoyer's firmware worked so well that I never investigated any further. I'll try and find some time to investigate the other options you mention.
I never fully understood the reasoning behind Andre's original design either, but (from memory) I believe it was to do with the fact that he expected the upper SRAM to be used a kind of "fast serial" storage bufffer - e.g. for video.
Fortunately, he cleverly arranged for the card addressing scheme to be able to be re-programmed to be pretty much whatever you wanted. Overall, it's a very useful experimenter's card.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina