--- Quote Start ---
LAI 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.
--- Quote End ---
The LAI interface is in my experience not adding any significant delay to the monitored signals. I have used it extensively in the past to monitor timing related issues and the signals that came out from the LAI pins exactly have matched the actual output pins. The LAI gives much more flexibility and ease of use when checking timing on various boards because i don't need to solder wires onto the device pins etc.
I have also previously compared the LAI/LA timing with timing information captured via the SignalTap feature and they correlate very well. To make sure, i just put the scope on the signals and the scope verifies the timing information acquired via the LAI pins and displayed on my Logic Analyzer.
--- Quote Start ---
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.
--- Quote End ---
The problem is that the receiving external FIFO i'm writing to requires a SLWR signal tsu of 13ns and a tsu on DATA_OUT of 5ns. Both signals require a th of 4-5 ns. I have not been able to meed the external hold times (now around 2-3 ns). I could use the PLL to introduce a phase shift since i'm using it for the 48 MHz signal but i would run into the same issue on both the 60 MHz and 120 MHz buses which also will need to be properly constrained and i don't have more PLL outputs available. I was hoping i could rely on the fitter to take care of all these details for me but it seems to be less than straight-forward.
Perhaps i would need to go back and start playing with the clock signals again. The last time i tried this it ended up becoming very messy which is why i wanted an alternative approach in the first place.
I also tried to double the set_output_delay (min) from -5 to -10 but i only noticed a mere 1ns improvement in th. Right now i'm rather confused. It bothers me that i'm not able to achieve the correct timing information by using the current approach. If i can't trust set_output_delay to adjust the timing i'm back to fiddling with LCELLs etc which is a major mess, really.
Thanks,
/John.
Honored Contributor
