Constraining Asynchronous I/O´s

Most people just don't constrain these and allow them to show up in the UCP report.

Some people will put a set_input/output_delay constraint on it, so it's not longer in the UCP report, and then add a set_false_path to it.

If you want an actual number, do a couple clock periods, something it could easily meet. You state that one reset could be at 2ns and one at 14ns and this would not be a problem. Constraints are generally supposed to show where it would be a problem, so if there is no condition, there is no need. That being said, I understand the safety blanket of wanting it bounded. There's always the, if it were 1000ns later, it might be a problem thought. Note that, even on unconstrained paths, the fitter will try to put things close together and use as little routing as possible, as this frees up resources for the critical stuff. It will always give constrained paths(that are tight on timing) priority on resources, but it's not like unconstrained paths will just be routed around the device a few times and be many tens to hundreds of ns long.