Useful Skew and Clock Scheduling
The idea
A path from flip-flop A to flip-flop B must fit its logic delay between A's launch edge and B's capture edge. If the clock reaches B a little late, the path gains exactly that much time; the price is paid by paths leaving B, which lose the same amount. Skew is therefore a budget to allocate rather than noise to eliminate. Fishburn formulated it: let t_i be each flop's clock arrival offset. With T the clock period, every setup constraint becomes
and every hold constraint becomes
t_i, t_jclock arrival offsets at the launching and capturing flip-flopsTthe clock period being minimizeddelay_max/minslowest and fastest path delay from flop i to flop jsetup, holdthe capturing flip-flop's timing requirements
Minimizing T subject to these difference constraints is a linear program, and pure feasibility questions reduce to shortest-path computations on the constraint graph (negative cycle means infeasible). The optimal schedule can cut the period below what zero skew permits, bounded by the mean cycle delay around the worst loop.
From schedule to silicon
Computing offsets is the easy half; implementing them means the clock tree must deliver prescribed non-zero skews: bounded-skew and prescribed-skew extensions of Deferred-Merge Embedding, or explicit delay insertion near specific flops. Modern tools apply the idea locally and conservatively (concurrent clock and data optimization): nudge arrivals at flops on critical paths, within tight windows, re-verifying hold everywhere, because aggressive schedules multiply verification corners and variation risk.
Where you meet it today
As 'useful skew' options in every commercial flow, in clock-and-datapath co-optimization steps, and in interview questions about why zero skew is not the objective, merely the safe default.