Simulation won't warn you. Only real hardware misbehaves when timing is violated.
Every gate takes a tiny bit of real time to settle — like a row of dominoes falling, or water taking a moment to flow through a pipe after you open a valve. If your clock ticks faster than the slowest chain of dominoes can finish falling, the next flip-flop captures a value mid-topple: garbage, captured cleanly, with no error message anywhere.
This is called a timing violation, and it's the number one cause of "works perfectly in simulation, fails mysteriously on the real board." Simulation checks that your logic is correct — it does not model real propagation delay by default, so a design can pass every single simulation test and still be electrically broken on real silicon.
The two numbers that define this window are setup time (how long before the clock edge the input must already be stable) and hold time (how long after the clock edge the input must stay stable). Propagation delay is how long a signal takes to ripple through a chain of gates. The critical path is the single slowest chain of logic between any two flip-flops in your whole design — and it alone determines the fastest clock frequency you're allowed to run the entire chip at, no matter how fast every other path is.
In your CNN pipeline specifically, the accumulator's critical path (the longest chain of logic between two flip-flops, e.g. through several adders in a MAC tree) determines the fastest clock you can safely run. Get this wrong and your registration outputs will show intermittent, seemingly random bit corruption that has nothing to do with your algorithm — it's purely the clock outrunning the physics of the chip.
Timing violations don't throw errors — they silently corrupt data that looks like it could be a real algorithmic bug. Knowing this concept exists before you start debugging real hardware saves you from chasing phantom software bugs that are actually a clock running faster than your logic can physically settle.