dnltz
commented
2 weeks ago Adding the DIE_AREA as parameter to density_fill seems to make it even worse and no filler cells are added anymore.
Open dnltz opened 2 weeks ago
dnltz
commented
2 weeks ago Adding the DIE_AREA as parameter to density_fill seems to make it even worse and no filler cells are added anymore.
maliberty
commented
2 weeks ago You can put large files in gdrive (or equivalent) and provide a link here.
maliberty
commented
2 weeks ago It would be helpful to see what those layers look like in the OR gui. Perhaps the IOs are marked as OBS.
maliberty
commented
2 weeks ago By default we only fill the core area. If you want to fill the die area you can use the -area flag.
maliberty
commented
2 weeks ago Adding the DIE_AREA as parameter to density_fill seems to make it even worse and no filler cells are added anymore.
-area looks to be operating in dbu rather than microns. I'll fix that but you can scale the area to see if it helps.
dnltz
commented
2 weeks ago What's the difference between dbu and microns?
Edit: Found it https://openroad.readthedocs.io/en/latest/contrib/DatabaseMath.html
dnltz
commented
2 weeks ago You can put large files in gdrive (or equivalent) and provide a link here.
https://fileshare.phytec.com/index.php/s/4G7nFdTPLpNTRpc
Can you download that?
maliberty
commented
2 weeks ago Units addressed in #5115 - for IHP the conversion factor is 1000
maliberty
commented
2 weeks ago If you look at Metal3 in OR you'll see the IO cells are fully blocked:
The most you could do if fill the gap between the ring and the die edge. Is that what you need?
maliberty
commented
2 weeks ago With the units fix + -area {0 0 1865.280 1867.320} I see it fully filled to the edges
dnltz
commented
2 weeks ago If you look at Metal3 in OR you'll see the IO cells are fully blocked:
The most you could do if fill the gap between the ring and the die edge. Is that what you need?
I can build openroad manually tomorrow and try your patch. Where is the IO blockage coming from? Can I disable IO cells in the PDK?
maliberty
commented
2 weeks ago It comes from the LEF. Filling inside the cell would be dangerous as without the OBS we would likely see it all as empty space to be filled.
stefanottili
commented
2 weeks ago There are three ways to generate fill: openroad, magic and klayout.
1) openroad operates on lef MACRO PIN/OBS whereas magic and klayout use "layout" aka gds/oasis input. 2) magic (used for sky130) requires a "magic tech file", which isn't available for a lot of technologies. 3) If you require the "interior" of pads/analog blocks/ram/rom to be taken into account when adding fill, klayout seem to be the way to go. But you'll have to find a way for capacitance extraction to read the klayout layout fill data.
maliberty
commented
2 weeks ago OR doesn't do FEOL fill so you'll likely need a second tool to handle that in any case.
In the longer term I think it makes sense to fill the core with OR, once it is timing aware, and then fill the periphery with a pure GDS tool. That thinking is why the default is the core area.
stefanottili
commented
2 weeks ago Slightly off-topic, but using this design as an example:
The current design finish stage using klayout with klayout.tcl calling def2stream.py can be replaced by strm2gds or strm2oas.
The one thing strm2oas can't do is to add a searing reference to the def DESIGN. But one can use a klayout txt file to reference both the def DESIGN and the sealring$1 in a new top. I prefer this hierarchy, but this might be a matter of taste. It xor's cleanly (when taking the missing iopad and bondpad gds from 6_final.gds).
q1) Is there a specific reason to have 551894 instance and net names as properties in the gds ? I've never seen any use for either of these needlessly bloating 6_final.gds[.gz].
q2) it seem geometry and fill in the sealring is overlapping the bondpads, is this intentional ?
q3) nor2b_1 and nor2b_2 are the only cells with a boundary layer 235, is this intentional ?
q4) The following two entries in the .map file are ignored by strm2oas and should be commented out. No need for instance names and a boundary rectangle for each instance bloating gds. 150 NAME COMP 63 0 152 COMP ALL 235 0
strm2oas \
--lefdef-no-implicit-lef \
--lefdef-macro-resolution-mode 2 \
--lefdef-map=\
../../OpenROAD-flow-scripts/flow/platforms/ihp-sg13g2/sg13g2.map \
--lefdef-lefs=\
lef/bondpad_70x70.lef.gz,\
lef/sg13g2_io.lef.gz,\
lef/sg13g2_stdcell.lef.gz,\
lef/sg13g2_tech.lef.gz \
--lefdef-lef-layouts=\
../../OpenROAD-flow-scripts/flow/platforms/ihp-sg13g2/gds/sg13g2_stdcell.gds \
def/6_final.def.gz,\
ElemRV.txt \
6_final.oasklayout ElemRV.txt
HEADER 600
BGNLIB 5/15/2024 15:45:45 5/15/2024 15:45:45
LIBNAME LIB
UNITS 0.001 1e-09
BGNSTR 5/15/2024 15:45:45 5/15/2024 15:45:45
STRNAME ElemRV
SREF
SNAME ElemRVTop
XY 0: 0
ENDEL
SREF
SNAME sealring$1
XY 0: 0
ENDEL
ENDSTR
ENDLIB strmxor \
--debug-level=11 \
--heal \
--threads=8 \
--tiles=500 \
gds/6_final.gds.gz \
6_final.oas
Describe the bug
OpenROAD can add metal fill correctly to the core area but is missing the area where the power ring and IO cells are located. See screenshots for more details.
The current design doesn't meet the ihp-sg13g2 DRC checks regarding some min density rules of 35%.
Expected Behavior
I was expecting the entire DIE area, not only the CORE area, gets filled with metal.
Environment
To Reproduce
External Link
Relevant log output
No response
Screenshots
Metal2 fill
Metal3 fill
Additional Context
No response