In the innovus tool, users often use verifyConnectivity to check open, winding integrity and other issues. For the winding results, especially the PG winding results, using this command can help the user to check the status of the closed connection of the PG during the power planning phase (used in pg DB, somewhat similar to S’s verify_pg_nets), the command’s Checkpoints include but are not limited to
- The overall penetration of PG: open check
- The macro's PG pin connection is closed
- Signal routing open check (signal routing open)
- Dangling Wire/Antenna Effect Check (DanglingWire/Antenna)
The first three points above are relatively routine inspections, usually without much ambiguity, but for the last DanglingWire/Antenna, INVS has its own unique way of understanding, here is a careful understanding and analysis of the following inspection items
Principle description of DanglingWire
DanglingWire description: wire usually refers to the physical shape of the net connected to a certain pin/terminal, and Danglng refers to whether there is any load connected behind the wire. If the wire is also connected to other input pins at the same time, due to this DanglingWire The existence of , will inevitably introduce potential antenna problems, which is why INVS marks DanglingWire and antenna together.
In the above topological structure, there are two connection relationships: U1.Z -> U2.A and U1.Z -> U3.A, and the corresponding actual physical routing is marked as the black and red routing above. This winding method will report a DanglingWire problem in the red part of the wire (wire) in INVS's verifyConnectivity evaluation.
The red part of the winding has no contribution to the closed structure of the winding, and it will also cause the winding of net1 to be unintentionally lengthened. Such winding will cause three effects:
- The red winding part will take up additional winding resources, but has no contribution to the database, so this is a waste of winding resources
- The red winding will make the RC of net1 larger, which will slow down the transmission of net1, resulting in undesired delay
- For the U2.A and U3.A input pins, since the windings corresponding to the input pins become longer, the red windings may cause more antenna violations of the input pins.
Due to the characteristics of PG via drop, this kind of DanglingWire situation is more common in PG winding. On the contrary, due to the unique algorithm of NanoRoute, DanglingWire phenomenon basically does not appear for signal connection.
The PG connection here is from M6 -> VIA56 -> M5. From the understanding of INVS, the rightmost part of this M5 wire (from the end of VIA56 to the rightmost end of M5, the red highlighted area) is a A small section of DanglingWire winding, because in the part of VIA56, this M5 has completed the mission of PG penetration, and the extra part is judged by INVS as DanglingWire without contribution.
When the PG is created, it cannot be fundamentally solved by the addStripe command. This is because the PG stripe is usually a two-horizontal and two-vertical layout, and there will always be a VIA56 farther away from the endpoint of the M5.
As shown in the figure above, although the VIA56 of VSS has been pushed to the far right in the PG layout, the DanglingWire of VDD is still unavoidable. It can be seen that when the user creates a PG. When using the same M6/M5, by adjusting the offset, the problem of DanglingWire can be alleviated, and the quality of IR can be improved indirectly, but the problem of DanglingWire cannot be solved.
A solution to the DanglingWire problem
The INVS standard for judging DanlingWire is: after the wire trace passes through the most effective connection VIA or load_pin, the winding length cannot exceed half of the trace width, otherwise it will be judged as DanglingWire
Take the above picture as an example, there is no DanglingWire violation for the relatively short M5 above. It can be seen that the right side of M5 is only 0.825um beyond the right side of VIA56 at this time , which is exactly half of the winding width of M5 (0.162/2) , and there will be no DanglingWire problem at this time. Corresponding to the lower M5, the length on the right side has not been trimmed, so the DanglingWire violation can still be seen.
According to calculations, in this example, by shortening the length of M5, about 7.375um of M5 winding resources can be released
DanlingWire problem understanding of Std-cell rail
Assuming that the currently designed std-cell PG rail is on the M1 layer, INVS’s focus on M1 is the same as that on M5. If the user does not perform any preplace std-cell planning and layout (including tapcell, endcap and other pre-place devices) , or the node of the replace std-cell is some distance away from the end point of M1, then similar DanglingWire problems will be reported in PG.
However, such an M1 DanglingWire will completely disappear when chipfinish, because all std-cell rows will eventually be covered with std-cells or std-fillers. The violation of DanglingWire on this M1 is not required on the PD DB. Forget about it, unless there is no need to place std-cell in this area, then users need to start with the clipping of site-row to save the resource occupation of std-cell
The same database, after entering chipfinish, M1's DanglingWire has been self-healed.
The difference between DanglingWire and open
After the above discussion, you should have a good understanding of the definition of DanglingWire in INVS. For ordinary users, the impact of DanglingWire is mainly to encroach on some designed winding resources (but pay attention to the change of load in different stages of DanglingWire. The shape of the violation will change to a certain extent, such as the above-mentioned DanglingWire problem of std-cell rail). In comparison, users should pay more attention to open issues.
INVS has two definitions for open:
- For the same net, but there are no wire pieces connected together, the definition here is more like the floating shape of the S family. If you are sure you don’t need it, you can also delete it directly
However, the more common open is the lack of VIA from M6 to M1. At this time, the user needs to deal with it in time, otherwise the final LVS will be difficult.
- PG pin not connected to the network: UnConnPin
One thing to note here is that INVS's verifyConnectivity is based on wire shape, so if you need to check the open or UnConnPin of a certain net, the premise is that this net has at least one wire shape, otherwise INVS will give the following prompts,
At the same time, NoRoute will be displayed in the Violations Browser: it means that the net does not have any wire shape
[Knock on the blackboard to draw key points]
DanglingWire in INVS is a potential waste of winding resources, which needs to be judged by the user and processed. On the basis of not affecting the IR analysis, the existing resources can be better utilized.
References
Cadence Innovus user guide
Synopsys ICC user guide
Cadence CDN support center