SRAM/flash expansion...
ImageCraft
Posts: 348
I suspect Andrea may have done it already for the Hydra, but I am not familiar with the Hydra system yet. Anyway, perhaps you kind folks have the answer: what does it take to interface 64K or above SRAM / fast flash to a Propeller and do it as fast as possible? SPI/I2C is too slow.
Thing is if it is fast enough, it's just as easy to use the external mem for LMM C program storage, then the bulk of the 32K can be used for data memory, and if one were to solve the (read) contention issue, especially in the general case of multi-Propeller access, then it would be perfect. A "low-end" 128K program memory, 32K data memory, 8 core Propeller system would just rock.
Credit goes to Bob Racko for the idea, whom I met again after 15+ years.
So many ideas, so little time...
Thing is if it is fast enough, it's just as easy to use the external mem for LMM C program storage, then the bulk of the 32K can be used for data memory, and if one were to solve the (read) contention issue, especially in the general case of multi-Propeller access, then it would be perfect. A "low-end" 128K program memory, 32K data memory, 8 core Propeller system would just rock.
Credit goes to Bob Racko for the idea, whom I met again after 15+ years.
So many ideas, so little time...
Comments
I'd like a good external RAM solution as well, for all or part of my 8080- CP/M emulator RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Too slow, you want a HW solution. Also, it won't work for multi-prop system.
1. Same way as Hydra, cpld to provide address indexing so you dont need pins for addressing. Looking at the driver for this card it takes 9 instructions per byte to read/write to the card. Though I thinking using counters could speed this up. The card uses 11 pins for 512K bytes
2. Use something like al440b which is a fifo but has an interface similar to I2C to set the start read/write addresses, so again you dont need pins for addresses. This has separate read and write pins so in principal you can read and write can the same time. I use them as an interface between a camera and the prop. I think you could also use them as a video output. You connect the write data pins to the prop, the read data pins to a resistor DAC and clock the read from a prop counter and you have a video system. If you use a counter to clock the write clock them you can use 1 instruction to read and byte and another to store it. So 8 instructions per long. This chip would take 12 pins for a fast read/write ram of 512Kbytes
3. The spi-sram that oldbitcollector found. Those are fairly fast you can clock them at 20Mhz. To get really fast you still need to parallel them, if you put 4 in parallel I believe you can access them in 30 instructions per long, with 8 in parallel its 14 instructions per long. It supports auto-addressing incrementing so you can burst large amounts in/out. For a 4 ram wide you use 6 pins for 128K bytes.
ee.usc.edu/library/ee459/datasheets/628128.pdf
Aren't there a number of different contention problems here:
1) Multiple COGs reading /writing a single byte (or whatever word size)
2) Multiple COGs reading/writing multi word array/structure
3) As 1 but with more than one Propeller
4) A 2 but with more than one Propeller
Solutions to 1) traditionally would use a dual port RAM but in this case we need 8 ported RAM !
2) Requires some kind of lock facility for mutual exclusion of processes. Just now I can't see any external lock mechanism being faster than the internal Propeller locks.
3) and 4) with multiple Propellers needs external hardware help probably from a CPLD or FPGA.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A 128K word-wide address latched SRAM/Flash could be done with the addition of two 74LS374 chips, but there would be little I/O left for other devices. You might be able to squeeze in TV DAC + SDIO interface or VGA, but that's about it.
Based on experience with my 1MB DRAM project, it seems an address latched SRAM might get about 3MB+ per second. Flash read access performance would be the same (writes are different of course). My DRAM project performance is about 1MB per second and requires about 3x the instructions of an address latched SRAM.
Higher density RAM can be had with DRAM with one 74LS374 and less propeller pins, but will be much slower than address latched SRAM without a complicated hardware assist. My protoboard has a 1M DRAM, but the only thing I've done with it so far is test that it works. I'm using a COG MMU controller written in PASM that could be easily included in a C library.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Using TV instead of VGA would allow more flexibility especially regarding pins 28 & 30.
My 6502·asm book has disappeared
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Edit: This is the schematic of the circuit i built (well just the pcbs I got)
The SRAM is a BS62LV1024 in TSOPII package. The board is the other image
Post Edited (Ale) : 7/18/2008 1:43:10 PM GMT
A side issue but important is that if it gets complex or costly, is it worth doing, would the target audience simply choose some other hardware platform in the first place or an alternative solution ?
I'd look at high-speed SPI memory first as the all-round easiest solution but I admit it depends on what need one is trying to address. Those who want to use C rather than Spin would probably accept some loss of performance set against being able to use C, those who want C with performance as close to native PASM as possible would perhaps be less accepting.
Many people have used pre-programmed micros which could be said to have truly atrocious performance which they are entirely happy with so speed may not be as much a problem as it is sometimes perceived to be. It of course depends on application.
Ale, that's a tight real-estate board. Using byte-wide SRAM helps to avoid "byte-lane" problems and reduces
the overal footprint. Will you post example code and performance measurements later?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any chance you'll have a couple extra PCB's made? I'd love to buy one of them from you if you do.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
is now apparently a reasonable connection-density-speed solution, it's time to make
interfaces that will use it or any other.
Hippy, the other media could be ethernet [noparse]:)[/noparse] You mentioned LMM; it is positioned to easily
use this by doing fetch in the LMM loop. For all the spin lovers, that means having an
interpreter or compiler that uses LMM .... What is the RAM interpreter status?
For C, it's just a matter of adding a fetch interface to the kernel and having an entirely
pasm interface for the SPI-SRAM. Putting "text" segment in external memory and leaving
variable references for "bss/data" in Propeller's internal memory would offer a good
solution since the data could be shared with pasm drivers. It's just a matter of fixing the
program.cmd linker map, and adding a fetch loop call. Of course one does not need
SPI-SRAM for this model, but a similar arrangement of SPI-EEPROM [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My own idea for a Propeller development board includes two 24AA1025's so I can have LMM programs up to 64K-longs in size. But I'm not particularly worried about poor performance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
@quantum, just looked at the fram and its the same pin out as the ram I used, except for the write protect pin which is NC for the SRAMs. So the same board with minor changes and same driver would work for them.
@oldbitcollector, yes I have a spare board but a warning theres no silkscreen though I didn't find it a problem putting it together. Drop me a PM.
I have been out of town for 3 weeks so no progress. Now back and implementing the changes. Just finished adding a debugger so I can validate my code against Chip's. I am using a different method than Chip·- I don't have the code restrictions he had. Updates will be announced on the forum under the title "Spin Interpreter - Faster ???".
I look forward to the wonderful things that can be achieved by having the interpreter in your (or anyone else's) willing and good hands. A debugger will be very welcomed by most new-comers and mosty anyone wanting either good direct evidence that their design assumptions are correct or just trying to unravel a mess. I look forward to your results.
Designing a way for fetching byte-codes from external memory would be a good step for you or someone to take after an initial release. Users willing to take the step beyond the 32K restriction should appreciate such efforts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The on board CPLD allows the RAM/Flash and IO to mapped anywhere in the device memory space
FEATURES SUMMARY
FLASH IN-SYSTEM PROGRAMMABLE (ISP) PERIPHERAL FOR 8-BIT MCUs
3.3 V±10% SINGLE SUPPLY VOLTAGE
2 MBIT OF PRIMARY FLASH MEMORY (8 UNIFORM SECTORS, 32K x 8)
256 KBIT SECONDARY FLASH MEMORY (4 UNIFORM SECTORS)
64 KBIT OF BATTERY-BACKED SRAM
OVER 3,000 GATES OF PLD: DPLD and CPLD
27 RECONFIGURABLE I/O PORTS
ENHANCED JTAG SERIAL PORT
PROGRAMMABLE POWER MANAGEMENT
HIGH ENDURANCE:
– 100,000 Erase/WRITE Cycles of Flash
Memory
– 1,000 Erase/WRITE Cycles of PLD
Post Edited (Praxis) : 7/20/2008 9:01:02 PM GMT
http://www.st.com/stonline/products/literature/ds/8586/psd834f2v.htm