RapidWright
RapidWright copied to clipboard
Trimming PIPs of pins on net one-at-a-time may not work
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.