Altera DDR3 traffic generator behavior question

[Altera_Forum]

Hello everyone, 

 Best wishes for the new year! Can someone please help me or provide some insight regarding the following:  I am using Altera's DDR3 Controller and - in conjunction with it - their traffic generator/checker IP driver_avl_use_be_avl_use_burstbegin. The latter drives the Avalon interface to the DDR3 Controller using internally generated patterns, reads the data back from the DDR3 DRAM and then compares against its stored expected pattern to generate pass/fail indications. Inside the driver_avl_use_be_avl_use_burstbegin module is a driver_fsm_avl_use_be_avl_use_burstbegin module which is the main driver FSM of the traffic generator. Within it, there is a 32-bit timeout counter and there is a check of this counter to see whether the last transaction timed out or not. From what I have understood of the design, a timeout happens if the DDR3 Controller does not give back the read data within the timeout period, or does not assert its ready output for a long time which stalls the traffic generator operations. What I dont understand is: What might cause the DDR3 Controller to EVER hold back its ready or not give back data for such a long duration? My Avalon clock is 200MHz, so 2^32 cycles of this clock is 21ns or so. Thats a very long time for the Controller not to give ready or valid, it seems. Can someone please throw some light on this? Many thanks, Arnab

[Altera_Forum]

The controller shouldn't ever trigger that timeout if everything is working and configured correctly. A failed initialization is probably a good guess for why you might trigger that timeout. 

 Are you hitting that timeout and wondering what is broken? Or are you just wondering why they even bothered to implement that timeout? The BIST IP is a useful tool for developing new or modifying existing memory controllers, so the timeout does have some utility.

[Altera_Forum]

Thank you for the reply, Ted. 

I do hit that timeout, and thats when I reset the IP while its operational, and then remove the reset to make it start again. I am wondering whether this condition could force a timeout, e.g. if the reset happens WHILE the IP was performing a write burst to the memory controller and the reset caused that burst to be prematurely terminated before its "burst size" got over, could that cause the memory controller to go into a sort of hung state and not respond to subsequent commands from the BIST IP, causing a timeout?

[Altera_Forum]

My suggestion would be to "keep it simple" - if you find yourself in a position where you want to reset any of the components (controller or BIST, in this case) - I'd just reset everything. I can imagine asynchronously resetting just the BIST might cause issues for either the DDR3 controller or possibly parts of the generated Qsys interconnect in between the two components. 

 I have used the BIST by manually or automatically controlling it's reset signal to chain together tests, but I was always resetting it only when it's "done" status output was asserted (no active burst possible).  But back to your problem of how you could possibly be getting a timeout in the first place, I'm not sure why that could be. My inclination would be to use Signaltap and characterize the last transactions leading up to the timeout and first determine if there is a pattern to the failure or if they are random.