Access EDO DRAM modules
heapdump
Posts: 13
in Propeller 1
Hi all,
I just asked myself if it would be possible to use an old 16MB EDO DRAM module with the Propeller 1 - these chips are cheap
and 16MB of course is much memory in that case.
data-sheet: http://www.pollin.de/shop/downloads/D101186D.PDF
Is it possible to access these modules?
And I just mean some basic access no direct code execution.
An other question would be, if it's possible to create some driver for propgcc as it exists for
the C3 board to drive external SRAM for indirect code-execution.
Thanks in advance and have a nice WE :-)
Patrick
I just asked myself if it would be possible to use an old 16MB EDO DRAM module with the Propeller 1 - these chips are cheap
and 16MB of course is much memory in that case.
data-sheet: http://www.pollin.de/shop/downloads/D101186D.PDF
Is it possible to access these modules?
And I just mean some basic access no direct code execution.
An other question would be, if it's possible to create some driver for propgcc as it exists for
the C3 board to drive external SRAM for indirect code-execution.
Thanks in advance and have a nice WE :-)
Patrick
Comments
I think that Brad? did some experiments with SDRAMs a few years ago, I tried it but didn't get much luck as (according to Brad?) I used a 74HC374, as that was what I had, whereas it had to be a much faster latch, at 3.3V to stand a chance of being reliable
There have been a few instances of AVRs doing it for CPM (at tranquilized slug speed), again, probably because of the 5V thing ...
Complete with 30-pin SIMM SDRAM memory module.
Might be some interesting schematics and code in there to see what you are up against.
I though I once found a video of that AVR booting Linux up to the Ubuntu graphical log in. Took about 10 hours. Can't find it now.
Of course, it would probably be easier to use the FPGA Prop 1s and get that "B" port. I do not have any FPGAs big enough, and you know how much I hate paying for stuff... I have been looking at Riston plastic sheet for photo etching PCBs... perhaps that will get me back making things again.
I might try this again sometime but I'd want a good source of chips so if I could get it to work, I could use it in multiple projects.
Jazzed mentioned getting EDO memory to work with the Prop in this thread. You might want to read some of the other posts in that thread since there are several posts about using large memory chips with the Prop.
DRAMs use those lines to set starting addresses, and then they have some burst ability from there.
The fish-hook with DRAMS is the refresh, so you have to not only 'use normally' but also scan one axis across the memory you want to use, for the refresh.
There is an upper time limit on that scan, before the memory literally leaks away. (usually some milliseconds)
You do not have to scan 100% of the device, if you do not use all of it, so you can test this with a small array first.
ie get smaller test patterns write/readback working, then make the array larger until it breaks.
Then tune the times to make it as fast as possible to support more memory area.
That would mean PASM, and a Counter to generate the refresh clock would help.
However, if you are going to take the time to code & test this, I'd suggest skip bin-parts, and use the new HyperRAM parts.
HyperRAM are cheap, and could have widespread use with Prop 1 and Prop 2.
They need fewer pins, with an 8-bit bus, and they have a self-refresh counter, but you do still have to worry about times a little.
A reference to 6 hours is there: http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit ...so 6 hours without GUI. Probably 10 hours with GUI is a very optimistic expectation...
http://www.issi.com/WW/pdf/66-67WVH8M8ALL-BLL.pdf
Digikey how good stocks of IS66WVH8M8BLL-100B1LI
Data says :
Configuration Register 1 (CR1) is used to define the distributed refresh interval for this HyperRAM device.
The core DRAM array requires periodic refresh of all bits in the array. This can be done by the host system by
reading or writing a location in each row within a specified time limit. The read or write access copies a row of
bits to an internal buffer. At the end of the access the bits in the buffer are written back to the row in memory,
thereby recharging (refreshing) the bits in the row of DRAM memory cells.
However, the host system generally has better things to do than to periodically read every row in memory and
keep track that each row is visited within the required refresh interval for the entire memory array. The
HyperRAM family devices include self-refresh logic that will refresh rows automatically so that the host
system is relieved of the need to refresh the memory. The automatic refresh of a row can only be done when
the memory is not being actively read or written by the host system. The refresh logic waits for the end of any
active read or write before doing a refresh, if a refresh is needed at that time. If a new read or write begins
before the refresh is completed, the memory will drive RWDS high during the Command-Address period to
indicate that an additional initial latency time is required at the start of the new access in order to allow the
refresh operation to complete before starting the new access.
The required refresh interval for the entire memory array varies with temperature as shown in Table 5.6,
Array Refresh Interval per Temperature on page 13. This is the time within which all rows must be refreshed.
Refresh of all rows could be done as a single batch of accesses at the beginning of each interval, in groups
(burst refresh) of several rows at a time, spread throughout each interval, or as single row refreshes evenly
distributed throughout the interval. The self-refresh logic distributes single row refresh operations throughout
the interval so that the memory is not busy doing a burst of refresh operations for a long period, such that the
burst refresh would delay host access for a long period.
Table 5.6 Array Refresh Interval per Temperature Device Temperature (Degrees C) Array Refresh Interval (ms) Array Rows Recommended tCMS (µs) 85 64ms 8192 4µs 105 16ms 8192 1µsSome of this is vague, but it looks like 64ms is one reference point, and 4µs is another, if you want to use the self-refresh features.
I hate to throw anything away, but all of the 30 pin SIMs went a long time ago. I did get the chance of some 4164s recently, but that was going to be all the hassle of DRAMs and needing 8 chips for just 64Kb, so that wouldn't be achieving the chip count reduction fetish.
I would have killed to get something like 64K on the sainted Nascom 1 back in '78 ish (if 4164s existed then?) and the Z80 would have helped along with the refresh stuff
Why don't you use a 128KB SRAM? Add a 74HC573 if you need a latch or two.
They are not expensive and easy to interface.
I also find a little more on HyperRAM interface here
https://warmcat.com/embedded/hardware/lattice/hyperbus/hyperram/2016/09/19/hyperbus-implementation-tips-on-ice5.html
Includes an interesting comment about Tacc being time based, and you can drop the Clock Latency from 6 (default) to as low as 3 (smallest documented) for slower clocks ( < 83MHz)
Boards with mounted HyperRAM show up has
https://shop.trenz-electronic.de/en/Products/Trenz-Electronic/TE07XX-Artix-7/TE0725-Artix-7/
https://www.altera.com/products/fpga/max-series/max-10/design-tools/ebv-hypermax-development-board.html
As for buying a board that has a HyperRAM on it think that I would be tempted to spend a bit more and get around to trying a FPGA Prop, with all of the lovely Port B possibilities.
Currently I use two ALLIANCE 628512-55 512KB SRAMs, this is OK so far for my applications,
but you have to pay around 12 euro for it.
Ouch!
AS6C1008-55PCN from Mouser $2.52 + shipping.
AS6C4008 is the 512KB version.
Sorry, I mean for both chips. Here in Germany you have to pay also around 5€ for the AS6C4008 (I just checked it),
but it's cheaper then the AS628512, thanks.