KEY: Incremental optimization re-runs on the updated histogram so the tool revisits the new top violators.

Hierarchical vs Flat Implementation

• Flat designs are generally preferred because they are easier to optimise.
• An instance keeps the same name (eg. A/B/C/D) in either style.
• When a design is flattened, the tool prepends the hierarchy to the instance name.
• In a flat design it is hard to split the work across multiple CPUs or threads.
• In a flat design it is hard to apply constraints separately to each module.
• Flat designs give better power, area and timing.
• Flat designs cannot grow too large in size.
• At SOC level, blocks are still divided according to their hierarchy.
• Other checks such as DFT and GLS also have trouble identifying constraints in a flat design.
• Once a design is flattened, it cannot be reverted to the original hierarchy.

KEY: Flat designs optimise better for PPA but don't scale, are hard to partition/constrain, and can't be un-flattened.

Analysing a Max-Transition Violation

Check the driver of the net:

• If the driver is too weak, upsize it.
• If the driving element is a non-buffer, insert a buffer at the driving pin.
• If the wire is too long, insert buffers to break the net length according to the buffer's drive capability.

KEY: For a max-tran violation check the driver: upsize a weak driver, buffer a non-buffer source, or split a long net.