Forum Discussion
Altera_Forum
Honored Contributor
17 years agoLAI output timings are not related to the IO timing at all(it would be impossible to do). LAI, I believe, is purely for looking at functional issues, not timing issues. You need to scope the outputs to see what is really happening.
Looking at the first hold path, it takes 17.244ns to get the data out, and the clock gets out in 3.373ns. This is at the slow model, where this really needs to be checked at the fast model too(which TimeQuest should automatically do, you're just not doing it when re-running TimeQuest), but I am quite certain it will make timing at that model to. So I think everything is working as you would like. To be honest, I don't like adding huge delays like this and relying so much on min models. Not that they shouldn't work, but you're relying on the fitter to do something right everytime(and it should), but you're really not taking advantage of the source synchronous interface, whose major goal is to send the clock and data with almost identical delays, and just have the clock phase shifted so it's centered on the data eye. For example, with the data, if you just inverted the clock in your design, either by having a tap of the PLL for it that phase-shifts it 180 degrees, or invert it on the output port(if you do the latter, you might have to add a -invert to the generated clock on the output port, I'm, not sure.) Now your output clock changes directly in the middle of the data you're sending. These track nicely over PVT, and that's why source-synchronous interfaces are required for high-speed I/O. It's just a suggestion, as again, what you have now looks right.