Games / Command flash cards / PD fundamentals / Interfaces and budgeting

Interfaces and budgeting

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 4 cards in this section, with answers
  • splitting a period across a block boundary
    One side's output delay plus the other's input delay fills the period.

    Hint: Two blocks share one cycle. Ask what stops them each assuming the whole of it.

    A path from a register in one block to a register in another crosses the boundary, and each side sees only its half. The budgets are the promise each side makes to the other, expressed as set_output_delay on one and set_input_delay on the other. the open flow reference

  • source-synchronous against system-synchronous
    The sender ships a clock with the data, rather than both using a common one.

    Hint: Ask where the clock that captures the data comes from.

    Sending a clock alongside the data means the two travel the same path and see the same delay, so the interface survives a flight time far longer than a cycle. It is how fast off-chip interfaces work, and it is constrained against a virtual clock rather than the core's. the open flow reference

  • what a block's timing model hides
    The internal paths, so an error inside the model is invisible above.

    Hint: Ask what the top level can no longer see once a block is a model.

    A model states the block's arrival and required times at its pins. If it was extracted with the wrong constraints or a different corner, the top level times against a fiction and closes on it. This is why models are regenerated whenever the block changes and are checked against the block's own analysis. the open flow reference

  • a feedthrough path across a block
    A signal that enters a block and leaves it, using it only as a route.

    Hint: Ask what a top-level net does when a block sits in its way.

    If a block occupies the space between two others, a connection either routes around it, which costs wire, or through it, which costs pins and a committed channel inside the block. Feedthroughs have to be planned when the block is built, since adding one later means rebuilding it. the open flow reference