Clock domain crossing of a gray counter. Any constraints / directives / cells?

How come you're not using the Megafunction FIFO? I ask, because it's been used/tested in many, many designs. (I really don't know of any designs that don't use it). Asynch FIFOs are a very difficult thing to design, and unless you've been studying for a long time and know all the ins and outs, will probably not work with high reliability. You may have a good reason, but make sure it balances out with the risk.

What do you mean compare the counters? If you're checking if they're equal, it's usually too late. By the names, I'm guessing your counters run at different frequencies, like 50MHz and 133MHz. So it's possibly to get 2 clocks of the faster clock before the slower clock has a chance to respond. The Megafunction FIFO, for example, will often raise a full/empty flag early, just to make sure it doesn't under/overflow. If no other read/writes are in the pipe, that flag will go low and allow the user to finish out their reads/writes. (Note that this doesn't happen often, but under the right circumstances it does, and I've seen people complain about it, but the fact is that this is the correct behavior).

And I wouldn't compare signals from two different clock domains. I know they're gray coded, but worry about that really working. I think the counters are usually gray coded and then passed into the other domain through a series of metastability registers before they are compared. (With gray counts, I don't think there's an easy way to do less than or greater than checks, just equals, so the actual compares may be binary comparisons, but that's only once the gray code value has been properly passed to the other domain).

Of course, creating your own FIFO for your own application may be a lot easier, if you know how it's supposed to operate. For example, if your FIFO is 128 deep, and you know you'll burst in exactly 128 and burst out exactly 128 at a time, and there's a determined space between bursts, then you don't need to compare counts, just make sure one side has passed a calculated threshold before the other side burst occurs. That's just an example, but if you can shape the behavior of your reads and writes, it might make the FIFO designing a lot easier.

In TimeQuest, you can do a set_false_path between domains in the .sdc. I don't think this is supported yet within the code(it was for TAN, and should be coming for TQ I imagine).