[DesignTools.deletePblock()]: utility to delete a pblock #1020
Conversation
Signed-off-by: Licheng-Guo <[email protected]>
There was a problem hiding this comment.
Thanks for the contribution @Licheng-Guo! Can you give a motivating use-case for when this method is useful? I think I'd like to see a testcase as part of this PR so it's no longer "untested".
@clavin-xlnx Since DesignTools is already so big, and since there could be more manipulation of the XDCs, perhaps we should create a new ConstraintTools class?
| * @param design The design to remove the pblock from. | ||
| * @param pblockName The name of the pblock to remove. | ||
| */ | ||
| public static void deletePblock(Design design, String pblockName) { |
There was a problem hiding this comment.
I would suggest calling it something more clear:
| public static void deletePblock(Design design, String pblockName) { | |
| public static void removeConstraintsReferencingPBlock(Design design, String pblockName) { |
| boolean containsPblockCommand = pblockCommands.stream().anyMatch(line::contains); | ||
| boolean containsPblockName = line.contains(pblockName); |
There was a problem hiding this comment.
Using contains seems quite brittle. Given pblockName is foo, the following would match:
create_pblock foobar... [get_pblocks notfoo]add_cells_to_pblock ... [get_cells foo]
Now the robustness of this is certainly limited by RapidWright not having a XDC parser, but I would still prefer to see some stricter matching, perhaps using regex.
The current design merger does not handle XDCs, thus the final output has obsolete constraints. One simple hack for now is to delete the ones no longer needed.
I can put a test DCP into RapidWrightDCP repo and add a test here
I think this is a good idea, we might need more XDC manipulation when stitching complex designs. I can move the utility over there |
Sure, I think a |
Utility to delete a pblock.
Only tested on Vivado-generated pblocks, i.e., those existing in an out-of-box Vivado DCP