Crossing into a faster clock is the friendly direction: the destination samples often, so levels are captured quickly and multi-cycle holds are easy to meet. The direction still has rules, and fast pulses can still vanish in the other direction's shadow.
Hold source levels for at least two destination periods, measured against the slowest destination period in any supported mode (gated, divided or sleep modes included).
A slow pulse wider than two fast periods may cross on a plain two-flop synchroniser; anything narrower needs stretching first.
Gray-coded slow counters cross bit by bit safely, and the fast side simply skips values between samples, which pointer logic must tolerate.
Handshakes complete quickly in this direction, so acknowledge latency is rarely the bottleneck.
A slow enable held for a microsecond into a 500 MHz domain is trivially safe: thousands of sampling edges see it stable. A slow-domain interrupt pulse of three slow cycles into a 4x faster clock spans twelve fast periods and crosses directly. But a single-cycle slow pulse into a clock only just faster, say 1.2x, spans barely one destination period and must be stretched to two before crossing.
Structural analysis treats slow-to-fast like any other crossing: two or more destination flops, no logic in the path. The review adds a ratio question: show the slowest destination mode and confirm the hold and width margins against it, not against the typical frequency.
The pulse spans one sleep-mode period, so it can be missed. Stretch the pulse to cover two periods of the slowest mode, or use a toggle scheme that needs no width assumption.
No. The fast clock samples more often than the counter steps, but it can still land on either side of several steps; skipping values is expected and pointer consumers must tolerate it.