Before you can read a line like tcq+tlogic+tsu+tjitter≤T+tskew, you must be able to see every one of those symbols on a timeline. That is the whole job of this page. We define each piece, draw it, and say why the topic cannot live without it.
Look at the figure. The blue line is the clock. The vertical orange marks are the rising edges — the only moments anything happens. The gray bracket marks one full period T — literally the span between one tick and the next. Everything in this whole topic is about when exactly those orange marks land.
The frequencyf is just how many ticks happen per second, and it is the flip of the period:
We use the reciprocal (one-over) because "how long each tick lasts" and "how many ticks per second" are two views of the same thing: make each tick shorter and you fit more per second. That is exactly the trade the parent note's max-frequency result is about.
Everything in this topic involves a launch flip-flop that sends data and a capture flip-flop that receives it, with some logic in between.
Follow the arrows: the clock (blue) fans out to both flip-flops. FF1's Q output runs through a cloud of combinational logic (gray) — AND/OR gates that compute something — and lands on FF2's D input. FF2 grabs that value on its own next edge.
Now we name each chunk of time. These are the letters that fill the parent's inequalities. Read them left-to-right as a signal's journey.
We must track both the slowest and the fastest path, because a late signal can miss the next tick (a setup problem) while an early signal can crash into the current tick (a hold problem). One number cannot describe both dangers — that is why the topic always carries a "max" and a "min".
The green band is the setup interval tsu (to the left of the edge) and the red band is the hold interval th (to the right of the edge). They are two separate windows with opposite directions. If the data (blue) wiggles inside either band, the flip-flop can go into metastability — an undecided, dangerous state. The parent's inequalities exist purely to keep the data out of these bands.
We finally have enough pictures to define the two words the whole note is named after.
Top row: the ideal ticks (evenly spaced). Middle: skew shifts FF2's whole comb of ticks sideways by a fixed amount (blue vs orange, always the same gap). Bottom: jitter leaves each single edge in a random fuzzy zone (red bands) around where it should be. This single picture is the difference the entire topic hinges on.
Read this as a signal's journey against FF2's next tick:
Tick fires at FF1 (time 0).
Wait tcq — Q appears.
Travel tlogic,max (slowest path) — reach FF2's D.
Must be steady tsubefore FF2's next tick, which sits at T, nudged by +tskew, and can be pulled early by tjitter.
Data needs tcq+tlogic,max+tsu; the deadline is T+tskew−tjitter. Requiring "needs ≤ available":
tcq+tlogic,max+tsu≤T+tskew−tjitter
Move jitter left (pure algebra) to match the parent's boxed form:
time the data needstcq+tlogic,max+tsu+tjitter≤time availableT+tskew
Hold is a different race, on the same tick. The new data FF1 launches at time 0 must not reach FF2 so fast that it overwrites what FF2 is still trying to capture on its copy of that same edge:
Tick fires at FF1 (time 0).
New data reaches FF2's D after only tcq+tlogic,min (the fastest path — the danger).
FF2's own capturing edge lands at tskew (same edge, just skewed), and jitter can push it later by tjitter, extending the hold window's reach.
The new data must arrive after the hold window closes.
Data arrives at tcq+tlogic,min; the hold window closes at tskew+th+tjitter. Requiring "arrives after the window":
tcq+tlogic,min≥tskew+th+tjitter