Large difference in measurements of area of same/identical polygons

Comments

• Matthias

  September 2019

  Hi sheppie,

  I hope I understood the problem correctly. To me this boils down to these lines:

  momcapTotal.sized(0.05).merge(0).with_area(2.5.micron2, nil).output(101,1)
  log("Total Area momcapTotal: #{momcapTotal.merge(0).area}")
  ...
  MOM = input(101, 1).merge(0)
  log("Total MOM: #{MOM.merge(0).area}")
  

  So as I assume "input(101, 1)" will read the layer that was written with "output(101,1)" your expectation is that the area will be the same, right?

  If that true, then the problem is about the difference between "in-place" and "out-of-place" version of methods. Here is an example:

  layer = ... # a layer (e.g. from input(...))
  
  # in-place version: will modify the layer
  layer.size(0.05)
  
  # out-of-place version: will create a new, sized layer and not touch "layer"
  sized_layout = layer.sized(0.05)
  

  So in the line

  momcapTotal.sized(0.05).merge(0).with_area(2.5.micron2, nil).output(101,1)
  

  "sized" will produce a sized copy and not modify "momcapTotal". "merge(0)" again is an in-place version (the out-of-place version is called "merged"), but will act on the sized copy. "with_area" again is an out-of-place version again.

  So in the end you produced a layer derived from "momcapTotal" and wrote this to the output, but you did not modify "momcapTotal". So when you compute it's area, the layer is not the one you have written.

  "merge(0)" is essentially redundant, as this is implied by all operations. So if your intention is to work with the modified version of "momcapTotal", the lines should be:

  momcapTotalModified = momcapTotal.sized(0.05).with_area(2.5.micron2, nil)
  momcapTotalModified.output(101,1)
  log("Total Area momcapTotalModified: #{momcapTotalModified.area}")
  ...
  MOM = input(101, 1)
  log("Total MOM: #{MOM.area}")
  

  With these changes, the results should be identical.

  The same scheme applies to the MOS area and gate layer.

  Matthias
• sheppie

  September 2019 edited September 2019

  Hi Matthias,

  Thank you for your very detailed reply. I'll test your solution today, and get back with results.

  Your assumption is right when you state "So as I assume "input(101, 1)" will read the layer that was written with "output(101,1)" your expectation is that the area will be the same, right?". I expect it to be the same. Moreover, when just looking at the layer, and toggling the visibility, it looked the same too.

  There's definitely something to learn here for me, since I just started writing code for KLayout DRC. And the "in-place" and "out-of-place" is relatively new to me. Previously I wrote code for Calibre, and I do not recall that there (with Calibre) was such a difference.

  With kind regards,

  Sjoerd
• sheppie

  September 2019

  Hi Matthias,
  I've updated the code according to your suggestions and it works perfectly now.
  Thank you for your support.
  With kind regards,
  Sjoerd
• dick_freebird

  September 2019

  Not pertaining to the subject per se, but interesting to see we have a Calibre expert lurking - getting klayout to understand a "golden Caliber tape-in deck" (as many or most of today's foundries insist to pass) would be kinda Holy Grail-ish.

  I've never seen a Caliber runset but seems to me that a translator utility is not outside of the possible (not that I could, but "somebody"...).

  Food for thought.
• Matthias

  September 2019

  Hi Jim,

  that's unfortunately a legal issue. Calibre's ruledecks are written in SVRF which is a format copyrighted by Mentor. It's strictly protected, so parsing it from open source tools is not possible.

  I wonder if any foundry might want to provide a KLayout version of their DRC. If they would like to, I'd assist. I just can't sign a NDA with them.

  Matthias
• dick_freebird

  October 2019

  This is actually on my plate, and I have not much hope of getting it done on time - creating a full foundry PDK for klayout (fixed geometry transistors, and SPICE models, are in hand; DRC, extract, LVS require translation from Tanner (ca 2010) format. But the foundry is pretty jealous of its 80s-vintage technology and wants NDAs. They also might want to control distribution of the kit, as just about everyone does.

  I'm not sure that anything prevents anyone reading a Caliber deck and figuring out how to do what they do, other than any documents you had to sign to get it in the first place. You would not be creating SVRF code, but equivalent functionality in Ruby or whatever. Not so?

  Would you consider a collection of

  Caliber: {width check example}
  klayout: {width check example}

  Caliber: {enclosure example}
  klayout: {enclosure example}

  ...

  translations, to fall under Mentor's copyright? I'd call it fair use.

  And then maybe somebody takes the next step and makes a perl, python, sed (whatever) script that rearranges arguments, badda-bing? One DRC check-class at a time....
• Matthias

  October 2019

  I'm just saying, an automated translation script would not be possible without violating copyright rules.

  A document describing the translation - well, I'd not do it myself, but I don't think this is forbidden.

  Regards,

  Matthias