Scratch DDR SDRAM Controller

There appears to be a bug in the control logic that allows the core to lock up. In either the read or write command, the first state sets an op and waits for an ack. Then the next state waits for busy_n to be released. Since the idle state is set up to clear the busy_n and to check for read or write commands (which set the busy_n) the core can get caught in STATE2 (for write) or STATE4 (for read) There are lots of ways this could be fixed. One way would be to clear the op code after it has been acknowledged. This would need to be done in both STATE1 and STATE3, with the STATE1 code shown below.

when STATE1 => op <= "10"; addr <= "0000000000"& x"6001"; data_i <= "11110001"; if (op_ack = '1') then -- begin new code op <= "00"; -- end new code
dram_driver_state <= STATE2; end if;

Thanks,

James

Apparently the opencores bug tracker can't handle vhdl code in the text. One more time with html tags around it:

when STATE1 => op <= "10"; addr <= "0000000000"& x"6001"; data_i <= "11110001"; if (op_ack = '1') then -- begin new code op <= "00"; -- end new code
dram_driver_state <= STATE2; end if;

when STATE1 =><br />   op <= "10";<br />   addr <= "0000000000"& x"6001";<br />   data_i <= "11110001";<br />   if (op_ack = '1') then<br />    -- new code<br />    op <= "00";<br />    -- end new code<br />    dram_driver_state <= STATE2;<br />   end if;<br />

Apparently, this thing doesn't really accept html either. It keeps erasing the vhdl non blocking assignment to clear the op register from 10 to 00 once the ack was received. It looked fine in a html editor on the web. I hope this is clear if anyone else needs to make the change.