setup & hold time
Picture passing a note to a friend on a moving carousel — you have to hold it out steady just before they sweep past, and keep holding it for a beat after, or the hand-off fumbles. A flip-flop grabbing data on a clock edge works the same way. Its data input can't be changing at the very moment the clock ticks; it needs a quiet window with the value held stable for a short stretch before the edge (the setup time) and for another short stretch after the edge (the hold time).
More precisely, setup time is the minimum interval the data must already be settled ahead of the active clock edge, and hold time is the minimum interval it must stay put once the edge has passed. Together they fence off a small no-fly zone around the edge during which the input must not move. The numbers are tiny — often tens of picoseconds in a modern process, and hold times can even be slightly negative — and they come from the internal delays of the sampling element that has to capture and lock the value.
Violate either bound and the flip-flop may latch the wrong logic level, or worse, hang half-way between 0 and 1 in a metastable state — an unstable balance that takes an unpredictable time to topple one way or the other, which can ripple bad data downstream. Keeping every path inside these bounds is exactly what static timing analysis checks. The setup check is the max-delay test: data must arrive early enough, so it sets the ceiling on clock frequency. The hold check is the min-delay test: data must not arrive too soon and race through to be captured by the same edge it was launched against — and, crucially, it doesn't depend on the clock period at all. The breathing room left over on either check is the slack.
always @(posedge clk) q <= d; // d must be stable around this edge in silicon
In an HDL model the requirement is implicit — you just describe the register and the tool enforces the timing later. The RTL says nothing about picoseconds; setup and hold are physical constraints that STA verifies on the synthesized netlist, not something the simulation of this line can see.
Setup violations can usually be cured by slowing the clock, but hold violations cannot — a hold failure is a race within a single clock period, independent of frequency, so a slower clock does nothing. The fix is adding delay to the too-fast data path (typically buffer insertion). That asymmetry is why hold violations are the more dreaded of the two: you can't just dial down the clock to escape them.