Another good thing here is that there are people already who have implemented a controller + several different phys (with DFI between them) in a python-based language called migen, which generates verilog code. This means that in best case we can reuse the parts that are known to work. DDR* is HARD, so doing unnecessary coding might not be all that beneficial.

Also, I forgot to mention in my previous reply is that we're already using a modified version of wb_sdram_ctrl to interface Altera's proprietary DDR controller, by only using the multi-port parts of wb_sdram_ctrl and having a Avalon-MM interface in the other end



Each port holds a separate cache. If several ports however contain the same addresses, they are all updated on writes in order to keep a constitent state. By default the cache is only big enough to store a full DDR burst.

From your reply it sounds like you have something implemented already. I didn't understand that from the previous replies. Do you have any code released?

If you are willing to go the extra yardage to test and prove a version of the controller with select lines, then lets make it the main version rather than a fork. My only problem is that I don't expect to be able to test the extra functionality, so if you can--all is better. The good news is, I think the change is simple and easy to make and I know where and how to make it (or so I believe).

In the meantime, while I feel like I've made a lot more progress today, the controller still doesn't work. If success is measured by the number of redesigns, I've redesigned quite a bit today (and yesterday, and ...)--hopefully success will therefore come soon!

Dan

I have some code available under the "memory" folder of my GitHub account. http://github.com/robfinch/Cores/blob/master/memory/
I'm using a slightly simpler architecture. If there is a write-hit on the nano-caches they are simply all invalidated instead of being updated, in order to remain consistent. The next read access (which must occur after the write) will reload a cache. Also there is only a single cache controller for all the nano-caches, since there is really only a single physical connection to memory. One final item that is handled is a memory reservation system on the cpu port in order to support semaphores.

Rob,

Looks like I was wrong and you were right on this memory. I'm trying to build everything for a 200 MHz clock, to support a DDR1600 memory, and just (belatedly) realized that the DDR1600 memory wants an 800MHz command clock (1600MHz data clock, if you will).

That means that if you run a wishbone bus at 200MHz, the memory will be able to read/write 128 bits every clock and not 32 like I thought it was. It also means I'm going to need to sit back and rethink my strategy a bit. In particular, I don't think I can keep an FPGA thinking at 800MHz. I can at 200MHz, just not 800MHz. So ... I'm looking at my drawing board again. Perhaps if I pipelined everything, parallelized the command port, etc.

Not giving up yet ... just looking at the drawing board again.

Dan