Forum Discussion
Altera_Forum
Honored Contributor
8 years agoHi Rysc and Kaz,
Thanks for your replies. I must say that I certainly appreciate the quick responses, especially from Gurus that I have read posts from before and always wondered if I would ever communicate with directly. I'm assuming you are the person who wrote the "TimeqQuest_User_Guide" Rysc. If so then thank you very much for that as well! Back to the issue.... After drafting another post with results and questions I think I found the answer to my delema. It became obvious when I ran "Report Clocks" as you suggested Rysc. The rise and fall times of the 100MHz clock are listed as 4.286ns and 9.286ns respectively. I noticed an entry in the "Phase" column for this clock of 154.3. This works out to be 4.286ns. When I checked the source code I found a phase offset being applied at the PLL to this clock (the 100MHz PLL). I would have assumed that this phase offset would have been accounted for in the "COMP" type path entry for FRACTIONALPLL_X96_Y2_N0 location of the Data Required Path (one of my previous attachments). But it seems that TimeQuest must relate this phase offset back by adjusting the launch/latch times. Which is a little confusing but I guess when you know about it its OK from that time on :-) I also notice that 300MHz clock is listed as being 300.03MHz in the "Report Clocks" report. I am guessing that this is due to rounding (3.333ns period) and that this clock is really 300MHz. Good to know about the set_max_delay solution for Timequest Rounding errors. Thanks again