Timequest: toggle synchronizer constraints?

For your collection, you've found how to get it's contents, but you could also do:

query_collection -report -all $regs

Is d driven by an input or a register? Let's say it's a register for the more complex case. To be "fully correct", you could put a generated clock on it, and basically describe the pulse based on the incoming clock. I assume the low-time is quite long, and it's how many clocks it is high for. That's a bit painful and probably unnecessary. You could put a create_clock directly on the register, in which case the delays to it are going to be ignored, but since they feed the launch and latch clock of the only path being analyzed, it really cancels out. (Yes, the rise/fall times will be different, but we're talking picoseconds, and I assume you have plenty of margin).

Now, the only path this clock will be analyzing is a toggle register. (You're right in that you would cut its timing from the clk, which could be done with false path of set_clock_groups.) And what are the odds that the delay of a register feeding back on itself is longer than the difference between pulse edges? I can't imagine that ever occuring, even if the pulse were on a 500MHz clock, there'd have to be at least a few clock cycles between edges.

As fvm points out, the pulsewidth could be an issue. If it's from a register, then the pulsewidth is going to be at least half the previous clock domain, and if it's not having issues than this one shouldn't.

I imagine most of the time, users wouldn't constrain this at all.

I tend to stay away from embedding constraints in the HDL. There are some very good uses for it. Heck, Altera does it in things like the DCFIFO, which is a great way to use it rather than having people add an .sdc for each FIFO and all the problems when they forget it. I find TimeQuest's way of embedding constraints to be clunky to say the least, and just not standard practice. It's easy to miss that these constraints are occuring. I know people that would strongly argue for embedding them, and I think it's perfectly valid and there are many good points, I've just stayed away from it.