Cyclone V hard memory controller clarification

Thanks Ted. That might be correct. It seemed too convenient of an answer.

My connections are as wide as the block allows with the the fifos that are built in (128 bits left for the 2nd port) and I am bursting at 128 words (experimented with lower).

I guess that you're saying that once the burst is initiated, it is locked in one command cycle until the burst is complete. If that is true, this shouldn't be my problem for the long bursts. I know that is true on the avalon side, but I wasn't sure that applied to the memory controller side.

I have been staring at the signaltap signals for a while but I'm new to troubleshooting these things.

I note that for short bursts in my situation they can practically get through with no wait states (but I know there is an efficiency hit with shorter bursts when it comes to the setup). On bursts that are 64 and 128 words long they tend to start seeing waitrequest asserted 15-20 words in and it remains more persistently active through the remainder of the burst. I have tried to probe at what I can find for signals indicating the refresh cycles and I can sometimes see a direct correlation with the stalls then, but I certainly do not have a crystal clear picture.

I didn't find a magic burst-size that bucked the 80% pass/fail threshold as I varied the clock up and down.

I built in some variables for tracking the fifos and the number of wait states (capturing the max for a given burst) so that when the failures occurred outside of what I could see in signaltap I had some idea of what went wrong. I'm sure I could trigger on those conditions if I were better with signaltap but it seemed easier to do it that way.

Thanks for the comments, I have more things to look at now.

Lance