Occasional Contributor
Super ContributorStill not clear. The file you're calling static_lvl_1.qdb: is this for the top-level static logic generated from the base revision or is that the .qdb for either parent1 or parent2? If it's supposed to be for the top-level static logic, then it has nothing to do with the logic contained in parent1 or parent2.
Better naming here perhaps: static_top.qdb for the top-level static logic compiled from the base revision and never changes. static_parent1.qdb for parent1 containing default persona logic for child1_1 and child1_2. static_parent2.qdb for parent2 and defaults for child2_1 and child2_2.
Now child1_1 and child1_2 could have their own other personas represented with bit1_1.qdb and bit1_2.qdb. Similar for child 2_1 and child2_2.
There will be a qdb for every part of this: top-level static logic, top-level parent logic that includes child default persona, and child logic when the child logic is supposed to be different from the default defined by the parent. So with this better naming, can you explain your idea?
Occasional ContributorSorry for the confusion. So, static_top.qdb is highlighted in yellow below. It has boundary nets(red) from the top level to the parent1 and parent2.
With static_top.qdb, if I subdivide parent1 into two children and subdivide parent2 into two children, I think I should get another static design for the level-2. I would call this as static_top_lvl_2.qdb, highlighted in green below. Note that boundary nets(red) propagate through the children regions. As we build upon static_top.qdb, boundary nets from top to parent1,2 are the same as static_top.qdb, and boundary nets from parent1,2 to children are routed down to children LL regions.
So the dark green area shouldn't contain anything. I am thinking of giving one row of fence so that boundary nets can be routed down to the children LL regions.
Does this make sense?
