What are taps in rail analysis, and why must they touch metal?

Short Answer

Taps are ideal voltage sources placed on the PG network to stand in for the pads, bumps or block pins that feed it; every drop in the rail analysis is measured from them. They are virtual models, not part of the design, so a tap only does something if it touches a PG shape on its layer. A tap with no conductive path to the supply network has no effect on the analysis, and create_taps (ICC2) warns about it with RAIL-305.

Technical Explanation

• Taps set where current enters the grid at full voltage; misplace them and the whole map shifts.
• -top_pg treats the top-level PG pins as taps and is meant for blocks without physical pad or bump information. -supply_net names the net explicitly; without it the net comes from the object the tap was defined on. The guide pairs it with -top_pg; the command reference says it is ignored there.
• -layer with -point creates a tap at absolute coordinates, and here -supply_net is required. If there is no supply net shape, pin or via at that spot, the tap has no conductive path and has no effect on the analysis.
• -of_objects places taps on the PG pins of pad cells or other instances, for top-level runs where pad cells are placed. -import reads a tap file with lines of net name, layer number and x y in microns.
• Simple package RLC models come in through rail.pad_files (ICC2), which requires enabling the RedHawk signoff licence key with rail.allow_redhawk_license_checkout (ICC2). If no pad files are given, you must create taps.
• By default the command checks each tap location, warns with RAIL-305 if it touches no layout shape, and records the result in is_valid_location, which later voltage drop and minimum path resistance runs update; -nocheck leaves it unknown. The guide and command reference differ on whether an invalid tap is kept or dropped, so confirm the tap count per net after creation.
• For an invalid tap created with -point and -layer, -snap_distance searches nearby shapes on the same layer and reinserts the tap at the corner of the closest valid shape. remove_taps (ICC2) deletes taps you no longer want.

What To Check

• RAIL-305 warnings in the log: the count should be zero.
• Taps with is_valid_location false after creation and after the first voltage drop run.
• Tap count and positions per net against the bump or pad plan.
• That every supply net you analyse has at least one valid tap.
• Any taps created with -nocheck, and the reason.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Zero RAIL-305 warnings, every tap valid, and 48 VDD plus 48 VSS taps matching 48 plus 48 bumps.
• Suspicious (illustrative): Tap count differs from the bump map, for example 44 of 48, or taps created with -nocheck whose validity is unknown.
• Hard stop: RAIL-305 on taps that stand for real bumps, a supply net with no valid tap, or signoff IR run with -top_pg on a design whose bump plan exists.

What The Interviewer Is Testing

• Understanding taps as the ideal sources that define where the analysis starts.
• Knowing RAIL-305 and the is_valid_location attribute, and acting on them.
• Choosing the right creation method for a block run versus a top-level run.

Follow-up Question & Model Response

"When is -top_pg the right choice, and when is it wrong?"

Candidate Model Response: It is right for a block-level run where the only known supply entry points are the block's top-level PG pins, which is the case it is documented for. It is wrong once real pad or bump data exists, because current then enters at pin shapes that may not match where the package actually feeds the die. At the top level with pad cells placed, use -of_objects on the pad cells; with a bump plan, import a tap file or use pad files.