So after some minor heartache, I’ve managed to get a working memory controller on the BEMICRO Max 10 board that is easy to use. It uses a wishbone interface.

The heart of the controller is from here but there were a few problems with it:

• It uses a burst mode of 2. For 16-bit RAM like the IS42S16400 chip that is found onboard the Max 10, this means the user interface is 32-bits wide. The planned use for this memory controller is with the J68 softcore 68000 CPU in our Hope Badge Computer. As a result, this CPU needs a 16-bit wide interface.
• It didn’t support byte masking. Byte masking is where you ask the controller to just return a single-byte from the lower or upper portion of the particular column location. This means that you might want the [15:8] portion of the 16-bit word, on the [7:0] portion of the 16-bit word. The CPU needs to support opcodes like “MOVE.B” — and needs a memory subsystem that can support it.
• There was a bug in the synthesizable test bench code sdram_rw.v. The bug involves the Maximum number of reads/writes during the test. This was set to an arbitrary 200,000 32-bit writes, which works out to be about 800KB. Well the chip is 8MB, so clearly this isn’t right. The right number is 2097152. * 4 (aka 32-bits) = 8,388,608. The right number of bytes.

The changes were relatively minor for the controller itself:

• Changing the MODE register from 12’b000000110001 to 12’b000000110000. (Set burst length from 2 to 1)
• Removing the WRITE1_ST and READ_PRE_ST states from the “data” state machine, simply skipping to the next state.
• Changing the wishbone interface bus widths to 16-bit instead of 32-bit
• Adding the SEL_I() wishbone interface to support byte-masking. I think this is right choice looking at the WishBone Spec.
• Pass the wishbone byte selection through to the DQM pins on the memory chip.

These changes will decrease the latency for a completed single cycle read by one. I have some future plans to add a cache to the front of the memory. I’ve got to read more about how these interfaces work and potentially add some priority arbitration in front of the controller.

This brings me one step closer to integrating the onboard SDRAM to the J68 softcore.