--- Quote Start ---
Sounds like a timing optimisation problem. Certain builds work perfectly and so it is unlikely to be functional error. The most possible culprit is at the bidirectional data to memory. To optimise this is a bit of headache if you want to follow the official rules of TimeQuest and delay measurements.
I suggest trial and error. Make sure all the registers are fast io. keep the Tco of various builds under control(may vary wildly if registers not fast io).
A good test is having a PLL to rotate the data clk in order to find best window.
--- Quote End ---
I was wondering if you could explain the idea of having a PLL rotate the data clock in order to find the best window. Does this mean change the phase offset of the data clock in order to see which offset allows for the launch/latch edges to match up?
I have had some issues with fast IO registers in the past, and tend to stay away from them.. but is it typical to assign output registers as fast output or fast input? There seems to be only exclusive settings (although I guess I could assign both fast input and fast output to a register.)
Edit:
I have been working on this issue quite awhile, and it seems I am optimizing in the wrong direction! With every timing constraint I add, it almost seems as if the design begins to fail even more, but I guess some result is better than none.
Can enabling duplicate registers under physical synthesis options change the design behavior? It appears as if a number of failed paths are derived from the duplicate registers.
Honored Contributor
