Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
eddieh-xlnx opened this issue Jul 26, 2022 · 0 comments
Open

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

eddieh-xlnx opened this issue Jul 26, 2022 · 0 comments
Labels

Comments

@eddieh-xlnx
Copy link
Collaborator

eddieh-xlnx commented Jul 26, 2022

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

Taking the same example as #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant