Constraining external ripple clocks correctly on external pin (pad_io)

Not wrong, but not what TimeQuest is using. (People use Tco for years and its worked fine). The one big thing is that Tco doesn't account for on-die variation or proper rise/fall comparison. With the proper constraints, TQ will compare on-die variation sub-models. So at the slow corner timing model, for example, there are two sub-models to account for the fact that not every delay will be pegged at the absolute worst under those conditions, i.e. on-die variation. So it has a fast and slow "sub-model". For setup analysis it will use the slow sub-model on the data path and the fast sub-model on the clock path. For hold analysis it will do the opposite. This will cut into your margin some. It also does rise/fall variation and looks at legal values. (For DDR, almost all combinations are legal, but if it were SDR, for example, it wouldn't use the clock fall time as it's being sent off chip, just the rise time since that is what is used to capture data at the far end).

It's not a huge difference from what you're doing, but I have seen in old designs where people compare Tcos and see them being off by 20ps or so, and thing that's how much skew there is. That's because both cases use the slow sub-model. In reality there will be more skew on Tcos.

(One example I always use as the issue with Tcos is to think of a 20ns clock driving an output through a register. TAN might report the Tco as being 7ns. Now let's say the user inverts the clock so it drives out on the falling edge. Is the Tco now -3ns, 17ns or 7ns? The answer is that it doesn't change, it stays at 7ns. So two different outputs, one clocked on the rising and one on the falling, whose outputs come out at very different times would have the same Tco. Another example is rather than inverting the clock, the user does a 180 degree shift on the PLL. What is that Tco? What about -180 degrees? I've seen users do almost -360 degree shifts on their PLLs because they get really good Tcos and they thing that will make a difference. With the TimeQuest way, by knowing what clock latches the data, all of this is accounted for. Sorry for the long explanation...)