Bug in memory controller


Recommended Posts

It has just come to my attention that in some cases back-to-back reads are broken in my SDRAM controller.


If the controller performs a back-to-back read to the same page it may end up stuck reading data until a refresh or another transaction interrupts it. The problem is that "got_transaction" is not reset to '0' during back-to-back reads, 


I'm just working on a test bench that exposes the flaw so I can verify the fix - the fix passes initial testing so if you think you may be experiencing this issue I can send you a patch ASAP.



Link to comment
Share on other sites

I think I found another issue myself, but this is related to my version. Actually I checked you current SDRAM controller implementation and it is largely different from my base version.


So, a couple of questions for you:


Does your latest version fully handles pipelined requests ? Most reads/writes from XTC will come from the caches, and they are bursted, sequential, and properly aligned.

How hard would it be to add tagging to it ? XTC heavily relies on tagging for memory accesses. Basically the tag is input at same time as the request, and it should come out at exact moment data is output. With XTC this tag contains all information needed for writing back to the register file, and to unblock pending reads on those registers (memory reads in XTC are not blocking, until you attempt to read the destination register).



Link to comment
Share on other sites

It does pipeline requests - with a queue that is at most two deep queue. While one transactions is in flight the next one will be accepted and queued up, allowing back-to-back reads or writes to be possible. Tagging could be added with just a two registers per bit of tag



I don't use FIFOs for commands & data queues, but it wouldn't be too hard to have them. It would use quite a bit of resources though.



Link to comment
Share on other sites


This topic is now archived and is closed to further replies.