Constraining Relative Skew in TimeQuest? Help!

[Altera_Forum]

How can I constrain relative skew among vector bits when using TimeQuest? In particular, how to do this while keeping the absolute flight time of the vector unconstrained? 

 Here's my situation: I'm trying to constrain a gray count that goes from one clock domain to the next. It's easy to show that the relative skew among the gray count bits must be limited to less than the cycle time of one LAUNCH clock. For speed reasons I want to keep the absolute flight time from LAUNCH clock to LATCH clock unconstrained.  I'm currently using set_min_delay and set_max_delay constraints, but this approach constrains the absolute flight time, something I want to avoid. Also, I'm getting fast model hold violations associated with the minimum delay, which is another reason I'd like a different approach.  Any help would be greatly appreciated!

[Altera_Forum]

Sorry, I don't have the answer to that one, but I'd be interested to know too, because I'll face the problem soon... 

Is it possible to declare one of the bits as a clock in TimeQuest and use it as a reference for the timing on the other signals?

[Altera_Forum]

Hello Daixiwen, 

 Our Altera FAE mentioned something along those lines, but later said that solution could only be applied to I/O, not internal signals.  When pressed he said I'll have to wait until next year when a future version of TimeQuest / Quartus will directly support skew constraints (and wait even longer for these constraints to drive place & route).  I don't get it. How in the hell are Altera async FIFOs working now? Relying on the multicycle default of setup=1 and hold=0 would almost certainly either overconstrain or underconstrain them (because multicycle is based on both the LAUNCH clock and the LATCH clock). Underconstraining is really dangerous here, and overconstraining might prevent timing closure.