feature request: apply blend-mode only to files concatenated by +, not by ,

[stefanottili]

If a cell with the same name is in two input files, the second one get's uniquified.
This can be changed with the --blend-mode=0, where their contents gets merged.

The help suggest that the --blend-mode would apply only to files concatenated by "+".
But it currently applies to both "," and "+", so one cannot distinguish what to do with different files.

strm2oas a1.oas,a2.oas+a3.oas out.oas => uniquified to "a$1 a$2 a$3"
strm2oas --blend-mode=0 a1.oas,a2.oas+a3.oas out.oas => both "a" in a2.oas and a3.oas merged into "a" of a1.oas.

1. I would have expected the blend-mode only to be applied to a3.oas.
   This way a1 would be left as is and a2.oas and a3.oas would be merged and uniquified to a$1, see a.merged_2_3.oas

2. I've never needed --blend-mode 1 or 2.
   So one could do away with blend-mode altogether and just treat "," as uniquify and "+" as "merge".

3. I'm using _ as the separator for unique names, strm2oas uses $, can that be specified ?

test_uniquify_merge.tgz

    --blend-mode=mode                            Specifies how cell conflicts are resolved when using file concatenation

          When concatenating files with '+', the reader will handle cells with identical names according to this mode:
          
          * 0: joins everything (usually unsafe)
          * 1: overwrite
          * 2: skip new cell
          * 3: rename cell (safe, default)
          
          Mode 0 is a safe solution for the 'same hierarchy, different layers' 
          case. Mode 3 is a safe solution for joining multiple files into one 
          and combining the hierarchy tree of all files as distinct separate 
          trees.

[klayoutmatthias]

Hi @stefanottili ,

Hmm ... I see people actually using blend modes 1 or 2. These are users who want to have their cells joined (if the names are the same), but not duplicated (like in mode 0) and no variants created by renaming. That is based on the belief that cell contents are identical if the names are. When the cells with identical names are standard cell leaf cells for example, this is probably a valid assumption.

It's not safe in general and I would like to discourage this use case, but if you know what you're doing the risk is acceptable and the solution is a lean one. And careful users employ an XOR step to verify the merge anyway.

Still, the suggested notation is interesting. Originally, the "+" and "," were introduced as synonyms. So, this is a semantic change.

As you are the power user of that feature I tend to follow your suggestion :)

Still: Modes 1 and 2 should have their own notation. How about "a1.oas<a2.oas" for mode 1 and "a1.oas>a2.oas" for mode 2?

And the notation would be serial, like

a1.oas,a2.oas<a3.oas

would mean:

• read a1.oas into layout L
• then, blend a2.oas into layout L in "uniquify" mode (3)
• then, blend a3.oas into layout L in "overwrite" mode (1)

[stefanottili]

Can you use <> on the command line ? They're pipe redirect characters in some shells, no ?

[stefanottili]

Maybe - and = are not used by shells ?
Or get back to my original idea of having , being 3 (rename), + by default being 0 (join) and if one want's 1 or 2, use --blend-mode=1 or 2 as option to change the meaning of +.

[stefanottili]

And lastly, I found it to be useful to be able to --skip_read_cell
This way one could avoid having to use --blend-mode=1 or 2 altogether and one can e.g. easily replace a rom or a fill-cell.

strm2oas new_rom.oas --skip_read_cell=rom chip_with_old_rom.oas chip_with_new_rom.oas
strm2oas stdcell_lib.oas --skip_read_cell=cell1,cell2,cell3,cell4,... block1.oas,block2.oas,block3.oas,top.oas chip.oas

This would require to change the command line "strm2oas input output" to change slightly in that this has to be able to be sprinkled in between files. "strm2oas input input output"

[sebastian-goeldi]

Can you use <> on the command line ? They're pipe redirect characters in some shells, no ?

Correct. But you can very easily escape this, use single quotes around them and the shell will interpret them as raw strings and not use <> for anything. This will be completely transparent to klayout cli as well

[klayoutmatthias]

Exactly. My reasoning was that these characters would not appear in (normal) file names, so they are safe to use as delimiters.

[stefanottili]

Ok

[klayoutmatthias]

After looking more closely at the request and the implementation I came up with the following proposal:

• "+" does "blending" and "--blend-mode" applies
• "," does "layout merging": Layouts are read into two different objects and then merged

"blending" does not allow mixed DBU (see #2066) and is less safe, specifically with "--blend-mode=0". But it allows merging identically named cells into one or elimination of duplicate cells.

"layout merging" allows using mixed DBU, but does not respect "--blend-mode" and will always rename cells to resolve cell name conflicts.

I understand this aligns with the original request and in general offers more options.

However, I am not able to preserve LEF caching for ","-joined files as the LEF cache depends on having the same layout objects. LEF caching still works on "+", which is somewhat in the spirit of this mode.

Matthias

[klayoutmatthias]

A proposal in in the branch attached to this ticket. Also #2066 (wrong scaling) is fixed in a way that incompatible DBUs are reported as errors.