DDR Runs Solo

The SOCoCo-80 Project

DDR Works solo

URL Posted

I got the DDR RAM working in a test module. The clock variable name problem was in fact the issue. This test code simply allows me to cycle up and down through the memory and read data. It also allows me to test the writing functions. However, the write function needs some work. The test function operation isn’t my final goal so I wont put any more time to it.

Soft 6809 Merge to DDR Memory

The next hurdle is to get the soft 6809 running using the DDR memory. Several issues need to be resolved with most complicated being the timing. When using SRAM the process is simple. The CPU reads and writes with no sync required. That’s an easy process. Been there – Done that. Using DDR is much more difficult. Accessing a memory cell in DDR memory is a sequence of events written in a state machine. The author of the driver used 2 base clock signals to perform the access. Each of these clock signals are running at 133MHz with the second clock shifted by 3nsec. In order for the CPU to talk to the RAM, the CPU clock must be synchronized with the RAM clocks.   Initially, I had planned on running the CPU at 50MHz. But I now see that I will have to slow the CPU down by a factor of at lease 4 to allow the state machines to cycle through their functions. I also found based on my test module that there will have to be an additional layer state controller between the CPU and the RAM module. This limitation is due to the way the original authors driver functions. After I get the system up and running, I plan on stripping down his driver and rewriting it to remove the layers. Hopefully, I will eventually be able to bring the CPU clock speed back to the 50Mhz arena.   The CPU/RAM merge starts this weekend. The mechanism that the DDR memory driver uses to trigger it’s operation it through three control signals. The WRITE, STROBE and CYCLE signals. Interestingly the STROBE and CYCLE signals seems to be the same timing. They can be combined into one strobe signal. I’m not sure what the thinking was here. Later I will alter the driver to combine these. The basic state machine concept is here:   STATE_ IDLE:            Wait for Read/Write trigger                                     Set state based on trigger type (i.e. STATE_READ or STATE_WRITE                                     Set WRITE bit for type (1=write 0=read)                                     Activate STROBE                                     Activate CYCLE   STATE_READ:           Wait for acknowledge                                     Read Data into buffer                                     Deactivate STROBE                                     Deactivate CYCLE                                     Set state back to STATE_IDLE   STATE_WRITE:          Wait for acknowledge                                     Write Data into RAM                                     Deactivate STROBE                                     Deactivate CYCLE                                     Set state back to STATE_IDLE     Now this is an oversimplified example. Other things need to be dealt with. The data bus on the RAM is 32 bits (driver defined). Although this needs to be looked at. 24 bit is all that’s needed to span the full 8 Meg. The read and write functions need to discriminate the bus down to 8 bits. Also the address space for the 6809 is only 65536 bytes. However, there’s 8 meg of RAM available. This also needs to be resolved. I plan on using a similar method to the CoCo3 with a ram block select register. This will be incorporated into the driver after I get the CPU running in low mwmory.   The basic concept of the address/data discrimination is to start with the CPU address ($0000-$ffff). The 8 Meg in the dynamic RAM is broken down to 4 banks of 1048576 16 bit words for a total of 4194304 16 bit words. This will be further broken in half (8 bit bus on the 6809) which gives us a total of 8388608 8 bit bytes available.     Well, that’s it for now.

© 2013 – Franklin Laboratories