Wishbone ACK sometimes missing?

[0xa000]

Got the Wukong example running. There are three different revisions of the Wukong board; For the board I have (V2), only the pins used for the LEDs are different, so that was an easy fix. Reading and writing via the UART works perfectly.

I'm now trying to integrate the DDR3 controller in a larger design. The controller is used in much the same way as in the example: 1) Wait for wb_stall to go low, 2) Start either a single read, or a single write, 3) Wait for wb_ack.

This works great for a few hundred transactions, but then the design locks up, seemingly waiting for wb_ack. The number of transactions after which this happens varies, but it's on the order of several tens to hundreds.

Is it expected that the DDR3 controller sometimes does not send an ACK, and if so, what would be the reason? For example, does the controller detect errors somehow and then refuses to send an ACK? (I have ECC turned off.)

[0xa000]

For reference, I'm on commit 93908acc9412dd2ebda7e670a02f36b2dd6a9497.

[AngeloJacobo]

Hi @0xa000 , it is not expected that the DDR3 controller sometimes does not send an ACK. UberDDR3 is Wishbone compliant and is formally verified so all input request should have a corresponding ACK.

I cannot say for now what might be the problem. But one way to test UberDDR3 is to turn off or set to zero the parameter SKIP_INTERNAL_TEST . This will add a built-in self test to UberDDR3 (might take 2 to 4 seconds to complete on hardware) where it will do write and read tests to all addresses of the DDR3. This is like thousands of write and read requests and should thoroughly test the Wishbone interface.

If this built-in self-test already passes on your Wukong board, it will be good idea to add more details on how the lock-up happens on your end.

[0xa000]

He @AngeloJacobo, good to know, thanks! I'll run the internal test.

[0xa000]

The internal test passes, I think. Both in the example, as well as with the controller embedded in a larger design. (That is, if it makes it to the DONE_CALIBRATE state with the internal tests enabled, that means the internal tests passed, right?)

Now trying to figure out why the larger design hangs.

[0xa000]

Hmm... the state machine using the DDR3 controller in the larger design really seems stuck waiting for wb_ack. If the controller always sends an ack for every request after the initial calibration / self test passed, then I don't know what's going on.

Could it be that sometimes a request posted to the DDR3 controller is not being accepted? Because in that case the state machine would also end up being stuck waiting for an ack.

The state machine does wait for wb_stall to go low before posting a request. I checked to make sure I didn't accidentally introduce an extra register on wb_stall, because I suppose that could cause the DDR3 controller and the state machine to have an out-of-sync view on this signal.

By adding a timeout, to get the state machine to "unstuck", subsequent requests to the DDR3 controller complete fine (until the state machine gets stuck again). That would indicate the DDR3 controller itself is not stuck. It's just that once every hundred or so transactions, the state machine does not see an ack when it expects one.

It's puzzling, for sure, but I doubt it's an issue in the DDR3 controller, so I'll close the issue. Should you have any thoughts or suggestions, please let me know. And thanks for creating and open sourcing the controller!