--- Quote Start ---
When you say I/O timing, do you mean through the LAI interface or what TimeQuest reports.
--- Quote End ---
I'm always measuring my timings with the LAI interface as well as scope to see the actual output timings. This is mostly because i am not yet comfortable trusting reports from Quartus but also because i'm not sure where to look for these numbers due to the c onfusing clock reference used. Measuring timing via LAI has been very accurate over the 2+ years i have used this method. Altera has probably made an effort to keep the LAI pin delays as small as possible to allow this.
--- Quote Start ---
The path I looked at added a 13ns route to your output path, which is something I have never seen done before, and I am certain is due to your timing constraints. So I still don't see the problem as it looks like what is occuring is correct(and impressive, as adding delay used to be very difficult for any FPGA fitter just a few years ago).
--- Quote End ---
I however wonder why 13ns is reported in the first place since the non-constrained timing (th) was only some 2-3 ns off. It seems to me a delay of 3ns should be sufficient.
--- Quote Start ---
You say adding 2-5ns would do, but you're saying it has to add 2-5ns across all timing models, which is difficult to do. My feeling is that you're trying to do something difficut(interface to a RAM that just isn't made to run at 48MHz), but it might be possible. What are the SLWR signals slack for setup slow model and hold fast model? You could attach those too, but it's a very tight window you're shooting for.
--- Quote End ---
I don't know the actual slack right now (i'm at my day job). How do i generate text-formatted reports for this? The receiving FIFO is an FX2 USB controller that is rated up to 48 MHz. It requires the timings i stated earlier per the datasheet. I have the option of sourcing the clock from the FX2 CPU, in which case the large 13ns setup requirement on SLWR will go down to around 4 ns. This unfortunately requires more changes to the design.
It looks more and more like the best route is to simply delay the 48 MHz clock so that the slack is spread evenly over tsu and th. I then should lock in the timing tsu/th with the SDC to constrain the design.
Honored Contributor
