Forum Discussion
Altera_Forum
Honored Contributor
16 years agoFirst off, make sure the spec is what you're saying. Outputs are often spec'd in terms of the input clock, i.e. the data is valid between 0 and 6.6ns after the input clock. This, by itself, is useless, since we want to know what the data output is in relation to the clock output. So if the clock output, in relation to the clock input, was 0 to 6.6ns, then we could figure out the skew between these.
Or is the spec saying the data comes out anywhere between 0ns(with the clock) up to 6.6ns after the clock? I don't know the answer, but it naturally makes a big difference. And skewed by anywhere between 0 and 6.6ns is a pretty big number(but not impossible). Now, your setup requirement is 7.5ns. So that only leaves 0.9ns of skew inside the FPGA. First, if using a PLL in source synchronous mode, it's possible that you can meet that. Secondly, don't forget that you have -7.5ns of hold to work with. So if you're just barely meeting setup timing and have tons of hold timing, then Quartus might be able to reduce the data delay to borrow some of that hold timing. Or, you can add a positive phase shift of a few nanoseconds to your capture clock. (And you would add a multicycle -setup of 2 between the external clock and the PLL clock to get the correct requirement). Bottom line is you still might meet timing, so give it a try. I do not think you need to go to a slower data rate.