Games / Command flash cards / PD fundamentals / Timing basics

Timing basics

Each card shows a command to explain. A missed card returns later in the round and starts the schedule over. A card answered correctly moves up the schedule and next appears after 1, 3, 7, then 21 days. Keys 1 to 4 choose an option, h shows a hint, and Enter moves on. A hint keeps the card where it is on the schedule. An ordering card is answered by clicking its items in order, and one wrong click ends it. Time values are in nanoseconds. Progress is stored in this browser.

SourceThese cards cover the reasoning behind physical design rather than any tool's interface: how a timing check is formed, what skew and variation do to it, and what the physical effects cost. Where an idea can be observed in the open flow, the explanation names the command that shows it, and the answer links to its documentation. Reference: the OpenSTA command reference (the open flow on GitHub).
All 12 cards in this section, with answers
  • the setup check
    Data must arrive before the capture edge, less the setup time.

    Hint: Write the inequality: data arrival against the next capture edge.

    Uncertainty comes off as well. Arrival is the launch edge plus the launch clock's latency, the register's clock-to-output delay, and the logic delay. Required is the capture edge plus the capture clock's latency, minus the setup time and the uncertainty. Setup slack is required minus arrival, which is what report_checks prints at the bottom. the open flow reference

  • the hold check
    Data must not arrive too early after the same edge that launched it.

    Hint: The two edges involved are usually the same one, not a cycle apart.

    Hold compares the fastest path against the same capture edge, so the period cancels out. That is why hold failures do not improve when the clock is slowed, and why they are fixed by adding delay to the data path rather than by relaxing the clock. the open flow reference

  • slack
    Required time minus arrival time: positive means the check passes.

    Hint: One number, formed from two. Ask which is subtracted from which.

    The same definition covers both checks because required time means different things in each: the latest allowed arrival for setup and the earliest for hold, where the subtraction reverses. Slack is the universal currency of timing closure. the open flow reference

  • the critical path
    The path with the least slack, which need not be the slowest one.

    Hint: Ask whether it is about delay alone, or about delay against a requirement.

    A long path with a relaxed requirement, such as a multicycle path, can have more slack than a short path on a fast clock. Optimization works on slack, so the critical path is defined by slack, and it moves as the design is fixed. the open flow reference

  • launch and capture
    The launching register's edge starts the path, the capturing register's ends it.

    Hint: Two registers, two clock edges. Ask which edge belongs to which register.

    Both edges come from the clock, but they arrive at different registers after different clock-tree paths, which is where skew enters. Writing a check as launch-side against capture-side is what makes the effect of skew, latency, and uncertainty easy to see. the open flow reference

  • why a multicycle path is safe
    The design guarantees the data is not used for several cycles.

    Hint: Ask what the designer knows that the timer does not.

    An exception is a promise about behaviour: an enable holds the capture register, or the protocol waits. If the promise is wrong the chip fails in a way no timing report will show, which is why exceptions are reviewed as carefully as they are written. the open flow reference

  • clock-to-output, setup time, hold time
    One is the register's own delay; the other two are requirements on its data.

    Hint: Ask which of the three is a delay and which two are requirements.

    Clock-to-output is how long after the edge the register drives its new value, so it is part of the path delay. Setup and hold say how long the data must be stable before and after the edge, so they are subtracted from the budget. All three come from the library and vary with slew. the open flow reference

  • why a synchronizer is a probability argument
    It makes failure unlikely enough to ignore, not impossible.

    Hint: Ask whether adding flops makes failure impossible or merely unlikely.

    A register that samples a changing input can sit between states, and it resolves after an unpredictable time. A second register gives it a full cycle to settle, which cuts the failure rate by orders of magnitude. The result is a mean time between failures, quoted in years, not a guarantee. the open flow reference

  • the fastest this design could run
    One over the period minus the worst slack.

    Hint: Slack is the margin at the current period. Ask how the two combine.

    Slack already accounts for the setup time, the clock skew, and the uncertainty, so shrinking the period by the slack is what the design can take. Note that skew and uncertainty do not shrink with the period, so the estimate is optimistic if the clock is scaled a long way. report_clock_min_period computes it. the open flow reference

  • a path from a rising-edge register to a falling-edge one
    Half a period, since the capture edge is the falling one.

    Hint: Draw the two edges. Ask how far apart they are.

    The timer pairs each launch edge with the nearest following capture edge, so mixing edges halves the budget. Between clocks of different periods it does the same over their common multiple, which can produce a much tighter requirement than either period alone. the open flow reference

  • a false path against a multicycle path
    A false path is not timed at all; a multicycle path is timed with more cycles.

    Hint: Both relax a check. Ask which one is still checked at all.

    A false path claims the timing never matters, so nothing is reported and nothing is optimized. A multicycle path claims it matters later, so it is still checked, against a different edge. Using a false path where a multicycle would do hides real failures. the open flow reference

  • time borrowing through a latch
    Late data passes straight through, borrowing time from the next stage.

    Hint: A latch is open for a while. Ask what late data can do in that window.

    Because a latch is transparent rather than edge-triggered, data arriving after it opens flows on immediately, so the overrun is passed to the following stage rather than failing. It is paid back there, which is why the total across stages still has to fit and why set_max_time_borrow caps it. the open flow reference