Timequest default setup relationship through PLLs

Run Report Clocks. Something looks wrong with your 100MHz clock. The 300MHz launch edge is at 3.333ns, which is correct, but the latch edge is at 4.286 when it should be 0/10/100, etc.

Note that coming out of different PLLs, you may end up with a rounding issue, but that would result in a 1ps setup relationship(9.999ns to 10ns), and not what you're seeing. If that were to occur, you would need to add:

set_max_delay -from clk300 -to clk100 3.333

And why not have the 100MHz come out of the first PLL? I assume there is a reason you're not showing.

Hi 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

Glad to hear you figured it out. The parameters you put into the PLL, like frequency(or multiply/divide), offset, duty cycle are ideal what the PLL looks like and will affect the setup/hold relationships. What then happens physically inside the device beyond that(PLL compensation, clock tree delay, input buffer delay, etc.) are then used as part of the clock path calculation but do not affect the relationships. This is good because the relationship is now calculated independently of what happens during compilation, what device you target, etc. Your slack will change, but not your relationship/requirement.

I know the TQ team has worked to prevent these small relationships from occurring due to rounding, so hopefully 3.333 and 10.0 don't get a 1ps relationship, but I'm not sure if it works across PLLs. (And if the clocks have a funky relationship, such as 2.345ns and 3.141ns, then a 1ps relationship may be correct.)

Finally, for the set_max_delay workaround, that's if all edges are rise-> rise. If you have any rise->fall or fall->rise, or just want to play it safe, I would do the following:

set_max_delay -rise_from clk300 -rise_to clk100 3.333

set_max_delay -fall_from clk300 -fall_to clk100 3.333

set_max_delay -rise_from clk300 -fall_to clk100 1.666

set_max_delay -fall_from clk300 -rise_to clk100 1.666

And if you do mix rise/fall transfers, the hold time changes. It's default is 0ns(when edge aligned, so you have to take care of the phase shift), but for cross-edge:

set_min_delay -rise_from clk300 -rise_to clk100 0.0

set_min_delay -fall_from clk300 -fall_to clk100 0.0

set_min_delay -rise_from clk300 -fall_to clk100 -1.666

set_min_delay -fall_from clk300 -rise_to clk100 -1.666

The one nice thing is you are loosening constraints in all these cases, so if you miss something then the path is overconstrained, but you'll never get the case where it's underconstrained and therefore passes static timing analysis but fails in hardware. (And you can also see that there is more complexity under the hood, whereby something as simple as a 100MHz clock and 300MHz clock has eight assignments to properly constrain it. And if you kept the phase-shift in then the values above would not be as symmetric either.)