RAM Expansion

Michael Popoloski

Would it be possible to use an SX chip as a kind of memory controller for the Propeller? I have seen some of the memory expansion designs floating around the forum and thought that much of the complexity could be reduced if you used a microcontroller, but I also thought that using another Propeller would be overkill. Also, it would be nice to have a good reason to get an SX chip and play with it a bit.

Bill Henning

Actually, that's one approach I am looking at, and Paul @ Parallax was looking at that approach before me.

The other approach is with bigger CPLD's or FPGA's than AndreL is using.

Michael Popoloski said...
Would it be possible to use an SX chip as a kind of memory controller for the Propeller? I have seen some of the memory expansion designs floating around the forum and thought that much of the complexity could be reduced if you used a microcontroller, but I also thought that using another Propeller would be overkill. Also, it would be nice to have a good reason to get an SX chip and play with it a bit.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Paul Baker

I was looking into using a microcontroller based design, first with an SX-48 then switched to Propeller because the 8bit architecture of the SX was just too constrictive on clock cycles to implement 24 bit increments, valid roll-over and a host of other features. But it all got put to the wayside to concentrate on getting the datasheet done. Now that is almost finished Andr

Michael Popoloski

So even if I used another propeller, it wouldn't be as fast as a CPLD?

Paul Baker

That is correct, while the Propeller is a parallel processor, a CPLD is hyperparallel, meaning that (within reason) any logical operation can be carried out in a single clock cycle.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

mahjongg

The CPLD is just used as "glue logic" in-between the PROP and the RAM, and serves two functions:

1) to provide for enough I/O lines to control a memory chip.
2) To create a memory interface circuit that helps to transfer memory content to the prop as fast as possible.

For example, to interface to a 512K static RAM (SRAM, dynamic RAM is also possible, but see below) You need to control 19 Address lines, and at least 8 data lines. plus four control lines ( /OE=Output enable, /CS=Chips select, /RD=Read enable and /WR=Write enable). That means you need 31 I/O lines just for that. Considering the fact that the propeller has 32 I/O lines, that does not leave much for the application. .

Perhaps you have heard of "dynamic RAM" (DRAM), and that it uses fewer address lines than static RAM. True, DRAM uses multiplexed address lines, which means you only need halve as much of them, so you only need 10 Address lines (for 1MB of RAM, or 20 Address lines), that would leave 10 I/O ports (actually a few less, because most DRAMS need more than 4 control lines) . But, and this is a big but, access to this RAM is much slower (even slower than my design, see below), and also you need to "refresh" SRAM which slows it down even more, and you need more software, so it's possible to use DRAM without support logic, but it's complex, slow, and you still only have a few I/O lines left.

So some glue logic is necessary.
I designed a minimal interface using just four common logic IC's to interface to 256K SRAM, and it only uses 10 I/O bits (one 8-bit port, and two control lines).
You can find my design here:
http://forums.parallax.com/showthread.php?p=629266

Andre's CPLD based memory is much, much more complex (I would need at least a dozen complex logic ic's to copy it), and uses 11 I/O bits (one 8-bit ports, two control lines, and a "clock" line), but it was designed with just one critical factor in mind, speed!

To maximize transfer speed (the speed at which you can transfer data from or to the RAM) you need to manipulate as few I/O lines as possible to transfer a byte of data. To optimize transfer speed Andre's design has partitioned the memory in two parts, the lower 64K of RAM which can be read out very, very fast, at any location (random access), and all the rest of RAM which only can be read at a much slower speed. The reason for this is that Andre's controller only needs to set a "pointer" into the RAM once, and after each byte of memory transferred the CPLD "updates" the pointer to the next byte automatically. The result is that the "memory pointer" does not has to be changed after each byte that is transferred. That means that he has to do much fewer manipulations of the I/O ports per byte transferred than my design.

To read (or write) a byte with my design, you first need to set a "command", then set the most significant address bits A16 & A17 (if changed), then another "command". then the upper address byte A8..A15 (if changed) and finally the lower address byte A0..A7 (if changed) only to set the "address pointer".
So for each of these three "command writes", you need (worst case, all three commands must be executed) to set the 8-bit output port six times, and manipulate the two control I/O ports twelve times (set them, then reset them), and that is just to setup the address pointer! Then to actually read the memory byte, you need to once more set a command, and then execute it, Then you need to setup the 8-bit port to input, and after manipulations of the I/O bits you can finally read the 8-bit data, and reset the I/O bits .
All this is needed to transfer just 1 byte!

In contrast, with Andre's design, you just have to control the 8-Bit I/O port twice (once for each of the two address bytes A0..A7 and A8...A15), and manipulate the three I/O bits six times (for one byte "strobe" first setup the control bits, then set and reset the "clock" bit) to set the memory pointer. But even better, after that you can read (or write) consecutive bytes by only once setting the correct command to read or write (which means setting the 8-bit port once, and then "strobing" the control and clock bits), and then programming the 8-bit port as inputs (when reading RAM). After that you can read consecutive bytes by just strobing the "clock" bit. And reading the 8-bit port. So that is -much- quicker than my design. Actually, it would be very hard to find a more optimal design, for 64K RAM.

So Andre's RAM is about as fast as you can get, at least for the first 64K.

The RAM above 64K in Andre's design can only be read (or written) by starting at the top of the 64K and then reading as many bytes as it takes to reach ("fast forward to") the "destination address" (using the hardware clock generator to strobe the "clock" I/O bit), after which you can read (or write) consecutive bytes as normal).
Still even with this limitation this RAM is much faster to read (or write) blocks of data from than a hard-disk!

Mahjongg