The-OpenROAD-Project
Adding obstructions shapes to write_abstract_lef
The write_abstract_left is dumping the shapes rects obstruction instead of the whole layer rect. The new steps:
- collect all the shapes per layer
- Bloat all the shapes
- Merged all the shapes if overlap ( per layer)
- Shrink back the merged polygon
- Decomposed the polygon into rects
( The process is in the image below)
The size of the bloat can be determine by the user ( with the -bloat flag), adding it also in the tcl procs, while the default amount is 2*pitch.
This is my first PR, so if there is any comment, suggest for improvement please let me know and I will work to improve it.
Super cool stuff! I wrote the original version of this code, and it's so cool to see it improved
I wrote an abstract for ng45/gcd and I see
LAYER metal4 ;
RECT 0.0 0.0 70.11 70.0 ;
LAYER metal5 ;
RECT 0.0 0.0 70.11 70.0 ;
LAYER metal6 ;
RECT 0.0 0.0 70.11 70.0 ;
LAYER metal7 ;
RECT 0.0 0.0 70.11 70.0 ;
LAYER metal8 ;
RECT 0.0 0.0 70.11 70.0 ;
LAYER metal9 ;
RECT 0.0 0.0 70.11 70.0 ;
LAYER metal10 ;
RECT 0.0 0.0 70.11 70.0 ;
which makes no sense since those layer are mostly empty but here they are fully blocked. How have you tested this?
for ng45/gcd the blockage for metal3 under various bloat choices:
0:
2:
5:
15:
The last looks like a reasonable model. I think the others are too detailed. I'm curious what others think...
Rather than gather all the obs and then merge them it would be better to merge them as you go. The set of objects to be merged could be huge on a large design.
This is an interesting abstract strategy but generally it seems undesirable. For most macros being abstracted, you want to mark any internal layers as "cover" blockages - the entire layer is covered with a blockage if any shapes exist on that layer. The reasons for this are that:
1, Computation is easier for the router 2. The LEF file size is reduced 3. It disallows routing near the internal nets of the macro, which could cause signal integrity violations that won't be caught by almost any other means. 4. Most macros should be metal filled before abstracting to ensure that the extracted parasitics and therefore timing models are accurate. In this case, the layer will be entirely blocked anyways.
It seems this PR changes the default abstraction method to bloating. I definitely think that if there is no bloating, the old method (which I believe is "all layers are cover layers") should be used.
for ng45/gcd the blockage for metal3 under various bloat choices: 0:
2:
5:
15:
The last looks like a reasonable model. I think the others are too detailed. I'm curious what others think...
15 looks better. Is there a good way to determine the largest bloat factor that would basically create a single sheet for each layer?
I think it is reasonable to have an option to just block the entire area as we do currently. I think that is a different option than -bloat_factor and a different 'algorithm'.
1, Computation is easier for the router
the point of the bloating is to trade off simplicity versus accuracy. Its why I objected to bloat 0.
- The LEF file size is reduced
Same as above
- It disallows routing near the internal nets of the macro, which could cause signal integrity violations that won't be caught by almost any other means.
We can easily add a final bloat option to increase the spacing as desired.
- Most macros should be metal filled before abstracting to ensure that the extracted parasitics and therefore timing models are accurate. In this case, the layer will be entirely blocked anyways.
Not if you want to be able to route through the area in question which is a goal here. Additional spacing / shielding removes most of the RC extraction concerns (inter-layer effects are still possible but can be conservatively modelled as they are smaller).
I'm not objecting to the functionality as long as the default behavior of write_lef_abstract is to generate obstructions for the whole layer. I think bloating is very useful in perhaps a few circumstances.
An ideal interface to me would look like
write_lef_abstract [-bloat_factor bloat_factor [-layers {layers}]]
Examples:
# Write an abstract LEF with cover obstructions on each layer
# There are still cutouts for pins
write_lef_abstract
# Write an abstract LEF with bloat factor of 15 on each layer
write_lef_abstract -bloat 15
# Write an abstract LEF with bloat factor of 15 on M4, M5
# All other layers use cover obstructions
write_lef_abstract -bloat 15 -layers {M4 M5}
# Write an abstract LEF with bloat factor of 15 on M4, M5
# Bloat factor of 0 on M6, M7
# All other layers use cover obstructions
write_lef_abstract -bloat 15 -layers {M4 M5} -bloat 0 -layers {M6 M7}
There is no need for pin cutouts unless they are not on the macro edge
It would be nice for consistency/compatibility with other abstracting/P&R tools. It is standard for IP to have pin cutouts.
There is no need for pin cutouts unless they are not on the macro edge
It would be nice for consistency/compatibility with other abstracting/P&R tools. It is standard for IP to have pin cutouts.
It is perhaps common but it isn't standard - you can see plenty of cases where that isn't true. lef/def specifically allow you to access pins covered by an obs.
Do we really need layer specific bloating? I'd rather not add complexity unless someone will actually use it.
What if someone doesn't want to allow routing on lower layers but is fine with routing on upper layers?
An example: top-level power mesh is on M6-M7. Signal routing is on M1-M5. Designer is fine with allowing external signals to pass through on M6-M7 but doesn't want signals passing through M1-M5.
Doing all-or-nothing bloating for the whole block seems like kind of extreme.
Just speaking personally, I would use this feature if I could free up routing resources on upper layers. I would probably not use it if I couldn't block all of the lower layers.
Ok if there is value we should add it. I am also ok to push it into a follow on PR.
You should update the src/README as this change would make the warning there obsolete.
Hi, I did some changes:
- Merge the polygon as we go, which supposed to easier for large design.
- I added insts ITerms to the obstructions
- Added the insts obstructions to the lef ( I am not sure about this one, please let me know if that what you meant )
There was other discussion about the this, but I don't understand what the conclusion, If you rather to do some change of the bloat_factor default please let me know.
There is a request to have an option for the old behavior. I don't like calling that '-bloat 0' and suggest we just add a different option like -block_occupied_layers. In a later PR we can allow users to choose the new or old style on a per layer basis.
So what is the next step here? Should I add this option to this PR and the next one? Any change needed regarding the previous requests?
I think you should add that change here as otherwise it would represent a loss of functionality for those who prefer the older style. Also you need to fix the CI errors.
I added the bloat_occupied_layers option, to cover the whole layer same as the previous functionality.
I would like to get some help with the CI errors, it seems that the build of the project are ok but it failed on certain test ( TestGuide) with undefine reference for dbITermShapeItr. I don't understand why it's failing since all the correct include are there and the build don't throw error on this.
The dependencies in odb are off. I'll fix that up and you can merge afterwards.
If you merge master to your branch this problem should be fixed (after you resolve the merge conflicts).
I merge with master and it looks like it passing now, except the lef test that failed as expected.
For the LEF tests - please verify that the new results are correct and update the test. You can use the save_ok script to do so.
I used the save_ok script to change the log too. But the DCO check always failed even when I use git commit -s, any idea why?