RapidWright icon indicating copy to clipboard operation
RapidWright copied to clipboard

Trimming PIPs of pins on net one-at-a-time may not work

Open eddieh-xlnx opened this issue 2 years ago • 0 comments

Also, it concerns unrouting the routing to a pin without removing the pin from the net.

Taking the same example as https://github.com/Xilinx/RapidWright/pull/472:

# (Numbers represent nodes)
0 -> 1 -> 2 -> 3 -> A_I
          +--> A_X

If I unroute A_X then the result is (correctly) that the routing doesn't change. If, however, I later decide I want to unroute A_I too, then because DesignTools.getTrimmablePIPsFromPins() thinks that A_X is still routed (based on the existing routing inadvertently using its node) then it won't rip up nodes 0-2 which is incorrect.

One solution I can think of is for DesignTools.getTrimmablePIPsFromPins() to only a node-with-site-pin as being used is if the SitePinInst.isRouted() is true. However, even though Net.unroutePin() and DesignTools.unroutePins() set the "routed" state to be false, a Design.readCheckpoint() does not currently set the routed state to begin with meaning it is not something we can rely on.

An organic example of this occurrence is on microblazeAndILA_3pblocks.dcp design's GLOBAL_LOGIC0 net, where the node INT_X32Y174/BOUNCE_W_3_FTS directly services the MMCME3_ADV_X1Y2/DI3 site pin but is also used to bounce to other nodes and downstream site pins.

eddieh-xlnx avatar Jul 26 '22 22:07 eddieh-xlnx