Games / Your move / Closing timing

Closing timing

Read the situation and the numbers it starts from, then pick the change you would make. Every option was run, so the answer comes from the measurement rather than from anyone's judgement, and after you choose you see what all of them did. Progress is stored in this browser.

SourceEach option in these situations is a run of the same design with one thing changed, and the table you see afterwards is what those runs produced. The answer is whichever run came out best on the measure the question names, which is not always the change that sounds most sensible.
All 7 situations in this kind, with their tables
  • Which change gets closest to the target?
    Nothing else, let repair fight it: 0.42 · Give it more room: 0.42 · Give back half the interface budget: 0.4 · Spread the placement: 0.42

    Three of the four land on 0.42 and one reaches 0.40, and it is the one that never touched the layout. The block was not short of room: it was short of period, because a fifth of the cycle was promised away at each port before the logic got any. Giving half of that back also costs the least area of the four, since repair had less to fix. Room does help a little, and spreading helps a little, but neither closes the gap.

  • Which change gets the worst slack closest to zero?
    Nothing, report it and move on: -42.82 · Ask for 340 picoseconds instead of 310: -12.8 · Give it room: -43.5 · Run the optimization pass the config skips: -42.82

    Only the clock moves the number, and even it does not close the block. Thirty more picoseconds leaves it 12.80 short, because the interface budget is a fifth of the period and grew with it: the path between the two flip-flops now passes with 1.34 picoseconds to spare, and the worst path becomes a flip-flop to an output port. Room makes it slightly worse, since spreading the cells lengthens the wires, 858 micrometres against 778. The extra optimization pass changes nothing at all, down to the same 331.69 picosecond floor and one micrometre of wire. Fifteen cells in a row is a synthesis result, and no floorplan knob removes a gate.

  • Which target gives the best timing?
    Leave the target at 38 percent: -1.46 · Drop the target to 25 percent: -1.33 · Drop the target to 18 percent: -1.4

    Room helps, and then it stops helping. Going from a 38 percent target to 25 takes the finished density from 92 percent to 60 and buys 0.13 nanoseconds. Going twice as far gives back less, not more: 0.07 nanoseconds instead of 0.13, on a block now spread thin enough that the wires cost more than the crowding did. The optimum is in the middle and neither end finds it, which is the argument for sweeping a knob rather than reasoning about which way it points. Worth noticing too what the target actually means: it is applied to the area synthesis produced, and repair then adds to that, which is how a request for 38 percent finishes at 92.

  • Which target gets the block to its real floor?
    Leave it at 2.2: 2.18 · Ask for 2.0: 2.05 · Ask for 1.8: 2.06

    The first thing to take from this is that the floor moved. A run that was asked for 2.2 reported 2.18 as the smallest period it could reach, and the same design asked for 2.0 reached 2.05. That number is not a property of the design. It is a measure of how hard the tools were pushed, and reading it as a limit will cost you performance you could have had. The second thing is where it stops. Asking for 1.8 gets 2.06, no better than asking for 2.0, and charges 7 percent more cell area and 31 percent more power for the attempt, with a total negative slack of -279 nanoseconds where the 2.0 run had -9.35. The block runs at about 2.05 and no request changes that.

  • Which way of adding margin costs the least?
    Ask repair for 0.10 of hold margin: 716 · Ask repair for 0.05 of setup margin: 899 · Tighten the clock from 0.46 to 0.40: 951

    The hold margin is free, and the reason is in the starting numbers: the block already had 0.11 nanoseconds of hold slack, so asking for 0.10 gave repair nothing to fix. It reported no hold violations and changed no cell. Setup is the other way round. With 0.02 of slack, asking for 0.05 sends repair to work on every path in between, and it costs 26 percent more cell area and 31 percent more power. Tightening the clock is the same idea taken further, and on this block it costs more still and fails to close. A margin costs nothing until it is larger than the slack you already have, and then it costs a great deal.

  • Which interface budget gets the best worst slack?
    Keep a fifth of the period at the ports: -12.8 · Give back half of it: 9.24 · Give back three quarters of it: 11.61

    Giving back half of the budget closes the block with 9.24 picoseconds in hand, a swing of 22 picoseconds from a change that touched no cell. The port path is still the worst one at that point, just passing now, with the path between the flip-flops 13.68 picoseconds clear behind it. Giving back three quarters leaves the port path 22.58 clear, and the internal path, at 11.61, becomes the limit again, so the extra budget buys only 2.37 picoseconds. Which path binds changed with every step here, and the only way to know which one you are fighting is to look at the endpoint, not the number.

  • Which target gets you the smallest block?
    Keep asking for 1.10: 5400 · Ask for 2.6: 4723 · Ask for 3.0: 4014

    An impossible target is not a harmless one. Asking for 1.10 grew the block 35 percent larger than asking for 3.0, and made it draw nearly four times the power, because repair kept upsizing and buffering paths it could never fix. What the chase bought is a floor of 2.56 instead of 2.66, a tenth of a nanosecond, which is the same effect the ibex situation shows: the reported floor moves with how hard the tools are pushed. Asking for 3.0 is the only one of the three that closes, and it is also the smallest and the coolest. A target should be something the block can meet, with a little room, because every picosecond it cannot meet is paid for in area.