klayout
klayout copied to clipboard
lefdef: strm2oas should write def if both lef and def are available
Reading multiple def files of a hierarchical design with --lefdef-macro-resolution-mode 1 strm2oas should be writing the def (layout) instead of the lef MACRO (abstract) if both exist. This way one get's a hierarchical oas with all the def (layout) and only the leaf-cells being abstract.
Is it really possible to read multiple DEFs into one? Do you have an example how you are doing that? I assume you're using strm2oas, right?
Thanks,
Matthias
strm2oas already coverts multiple def to individual oasis cells. But when also converting lef to cells using --lefdef-macro-resolution-mode 1 for all the def files you want the def (layout), not the lef (abstract). Write lef only for the leaf cells.
I guess I understand the idea, but I'm kind of reluctant to implement it easily.
Problem is that - unless I impose some file naming rule - I cannot say which DEF file a macro is in. So in order to find whether a macro found in a LEF file is also in a DEF file I'd basically need to scan all *.def files next to the main one plus be aware of potential conflicts (e.g what strategy to pursue if a macro is present in two files).
I feel scanning a folder for files is somewhat intrusive and may lead to incorrect conclusions. I can't really say if a bunch of *.def files is only a collection of macros or supposed to form a (potentially multi-level) hierarchy. For LEF that is obvious as LEF macros are always leaf cells while the DEF is the top one.
For safety I could enable this scan with an option, e.g. --lefdef-recursive-def or something like that.
Matthias
no need to scan any files, just read lef/def. Remember whether a cell is read from lef or def. When writing, first write all the cells from def and then don’t write any duplicate. This will avoid writing the lef cells for which def cells exist.
You mean the DEF is already hierarchical?
I don't get it, I'm afraid.
A def component is just a reference (gds sref, oasis placement). And so a def file can reference a different def file, aka hierarchy. You need to read the lef for a referenced def to get the SIZE, so that the + PLACED x y coordinates can be adjusted since def uses “lower left corner”.
Have a look at the hierarchy in the test_origin_hier testcase.
Currently strm2oas writes the lef cells uniquified (name$1) and the def cells. So it writes multiple toplevel cells. It should only write the lef cells if there isn’t a def cell of the same name.
Okay, so I assume you're using "top.def+macro1.def+macro2.def+..." to join them?
It’s not joining at all, every def creates a separate cell. Think of a def file as a gds file with one struct and lots of unresolved references. Just that you need lef to get the reference coordinates right.
Well, I mean the following:
Assume you have a top.def with design TOP placing two macros A and B, a LEF called blocks.lef with macros A and B and corresponding DEF files a.def and b.def.
Then you can do:
stream2oas top.def+a.def+b.def out.oas
This will give you a cell TOP with references to cells A and B which contain the LEF abstracts from a.lef and b.lef respectively. plus you have cells A$1 and B$1 with the DEF content for a.def and b.def as separate top cells.
The reason for that is not the DEF reader or OASIS writer, but blend mode. Just reading "top.def" will read TOP with the LEF abstracts for A and B. blending in a.def in addition (by using "+") reads A from a.def, but the default blend mode is "rename", so this becomes "A$1". Same for b.def which becomes "B$1".
To fix this you can use:
stream2oas top.def+a.def+b.def out.oas --blend-mode=1
Where the "1" is for "substitute".
Matthias
nope, one cannot just read multiple def files without their corresponding lef files. Lef is needed for the PLACEMENT coordinate adjustment (unless it's orientation N) and possible ORIGIN/FOREIGN offset.
Have a look at the test_origin_hier testcase, add a rule for strmlefdef. Its hierarchy should look exactly as the one generated by strmdef.
Currently top references uniquifed lef cells a$1, b$1, c$1 and the def are additional toplevel cells a,b,c. top should reference the def cells a,b,c and not convert any of the a,b,c lef's because there are already def cells for them.
strmdef:
strm2oas
--lefdef-lefs=tech.lef,blocks.lef
--lefdef-no-implicit-lef
--lefdef-map tech.map
--lefdef-macro-resolution-mode 2
top.def,a.def,b.def,c.def
strm2oas.def.oas
strmlefdef:
strm2oas
--lefdef-lefs=tech.lef,blocks.lef
--lefdef-no-implicit-lef
--lefdef-map tech.map
--lefdef-macro-resolution-mode 1
top.def,a.def,b.def,c.def
strm2oas.lefdef.oas
We're pretty close :)
I skipped blocks.lef in my description.
"top.def,a.def,..." is equivalent to "top.def+a.def+b.def+...", so what actually hits here is the "blend mechanism". It's already messed up by the reader and "--blend-mode=1" should force the reader the substitute the LEF abstracts when reading the later DEFs.
Matthias