reading multiple def with strm2xxx adds $1 to cell name, but not to reference

[stefanottili]

Using strm2xxx to read multiple def creates the correct reference to "sub", but despite asking for --lefdef-macro-resolution-mode 2 where no cell should be created for the MACRO, klayout thinks a cell with the name sub already exists and wrongly adds $1 to sub when reading the sub.def. Thus there are two top-level (top and sub$1) instead of one where top is referencing sub and top has an unresolved reference to sub.

strm2oas --lefdef-lefs sub.lef --lefdef-no-implicit-lef --lefdef-macro-resolution-mode 2 top.def,sub.def k.oas
test_hier_defin.tar.gz

[klayoutmatthias]

Shouldn't DIEAREA have two coordinates? Like:

DIEAREA ( 0 0 ) ( 200 200 ) ;

anyway ...

The problem is that blend mode is only implemented for GDS + OASIS for now. That means that when you have a cell "sub" (even if it's a ghost cell), reading another "sub" will mean it is renamed.

I have implemented blend mode for DEF+CIF too, which means your strm2oas call works as expected, because the default blend mode will attach sub.def's top cell to the "sub" ghost cell created in top.def. Rigjh now that is in branch lefdef-enhancement.

Out of curiosity: Is this how one generates a twofold DEF hierarchy? I mean, is that a standard way? Basically this could go on forever and generate a multi-level hierarchy with many DEFs.

Matthias

[stefanottili]

branch lefdef-enhancements Reads hierarchical def, no difference between def,def and def+def, yay. strm2oas \ --lefdef-map a.map \ --lefdef-lefs lef/all.lef.gz \ --lefdef-no-implicit-lef \ --lefdef-macro-resolution-mode 2 \ --cblocks \ --strict-mode \ def/top.def.gz,def/block0.def.gz,def/block1.def.gz \ klayout.oas

[klayoutmatthias]

Very good. Scheduled for merge! :)

[stefanottili]

Yes, it should DIEAREA should have two points. (and there is that case of OBS having a polygon for non rectangular blocks) You should treat def exactly has you treat gds/oasis. The only difference being that for reading def you need lef tech info (default net width per layer, via, viarules, non default rules) and lef MACRO SIZE to be able to read the components that are not N(worth). KLeep the MACRO SIZE in the background, don’t convert macros to cells yet. You should think of the def components as oasis placements or gds sref/aref without having the underlying cell. For reading def, there is no reason to have “ghost cells” or having to “merge” cell geometry. There is no differnence between def or gds/oasis hierarchy, def components are just unresolved references (placements). Only for the (arguably rarer) case that one would want to convert the MACRO geometry to cells to be able to look at def/lef, only then would one convert the MACRO geometry to cells and only for the components that are referenced. Same for via, only write the ones that are used. And if you have a lef MACRO of a def DESIGN, then you won’t convert the macro to a cell because you already have the def for that. The last case is to “just” read lef MACROs, in this case you want to convert all the MACRO to cells. Just as if you would read a gds/oasis std cell library.

…

On Apr 2, 2022, at 10:57 AM, Matthias Köfferlein ***@***.***> wrote: Shouldn't DIEAREA have two coordinates? Like: DIEAREA ( 0 0 ) ( 200 200 ) ; anyway ... The problem is that blend mode is only implemented for GDS + OASIS for now. That means that when you have a cell "sub" (even if it's a ghost cell), reading another "sub" will mean it is renamed. I have implemented blend mode for DEF+CIF too, which means your strm2oas call works as expected, because the default blend mode will attach sub.def's top cell to the "sub" ghost cell created in top.def. Rigjh now that is in branch lefdef-enhancement. Out of curiosity: Is this how one generates a twofold DEF hierarchy? I mean, is that a standard way? Basically this could go on forever and generate a multi-level hierarchy with many DEFs. Matthias — Reply to this email directly, view it on GitHub <#1048 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGFBQUGMEFEOPOYFNBXFLH3VDCDANANCNFSM5SGOVCUQ>. You are receiving this because you authored the thread.

[klayoutmatthias]

Thanks for that explanation.

But I'm having some trouble understanding: when you say "...placements or gds sref/aref without having the underlying cell" this is exactly what qualifies a "ghost cell" in GDS (there is no such thing in OASIS as there it's an error not to have the cell). And "merge" is a use case for GDS where one file has the aref/sref and the other file has the actual cell. So merging the second file into the first one substitutes the ghost cell and makes it a normal cell.

Isn't that the same thing you like to have for DEF components?

Matthias