Some DRC questions

Comments

• Matthias

  July 2020

  Hi Jim,

  Regarding 1:

  I wonder why no one has asked this before ... Actually there is a way to include files, but it's slightly clumsy currently.

  It should be as simple as this:

  include "include_me.drc"
  

  However, it's not. Ruby, like most modern languages, isn't a pure scripting language and puts some obstacles between you and executing text as code.

  First of all, the notation for including a file is this:

  instance_eval(File.read("/path/to/include_me.drc"))
  

  However, you probably would like to look up the file next to the current one, so you can let Ruby resolve the path relative to the current file:

  instance_eval(File.read(File.join(File.dirname(__FILE__), "include_me.drc")))
  

  This works, but is somewhat difficult to debug as you won't see the file name if some syntax error occurs. This can be fixed by supplying the file path once again to "instance_eval". For not replicating the code, I write it this way:

  include_file = File.join(File.dirname(__FILE__), "include_me.drc")
  instance_eval(File.read(include_file), include_file)
  

  But there is another problem: an included file can't create variables in the calling file. Ruby is semi-compiled and variables cannot be created dynamically. As layers are variables too, the need to be declared before the file is included. On the other hand, this allows temporary layers created inside the included file which will not be visible outside. So some kind of encapsulation.

  But included files can see variables from the calling file.

  Here is an example:

  # declare the variables m1 and m2 for the layers. You can use any number of 
  # variables here
  ( m1, m2 ) = []
  
  sizing = 2.0.um
  
  include_file = File.join(File.dirname(__FILE__), "include_me.drc")
  instance_eval(File.read(include_file), include_file)
  
  log("m1.area=#{m1.area}")
  log("m2.area=#{m2.area}")
  

  and the "include_me.drc" file:

  m1 = input(1, 0).sized(sizing)
  m2 = input(2, 0).sized(sizing)
  

  I'm using this scheme myself in one case where I use a wrapper providing the run specific variables and let it include a bigger core script to provide the actual implementation.

  I need to work on this a little - it probably can be simplified somewhat. But I don't know it it's possible to overcome the variable scope limitation.

  Regarding 2.)

  You can always add other locations by using "Add Location" from the DRC list context menu. So if you like to keep your DRC scripts somewhere in "/opt/drc/my_fancy_tech", then just add this location to the list and you can use the DRC scripts from there too.

  You can basically add any number of locations you want.

  It's also possible to use an environment variable called "KLAYOUT_PATH". If KLayout sees such a variable it will add the "$KLAYOUT_PATH/drc" path to the list of DRC locations (multiple entries can be given).

  And finally, you can keep DRC scripts inside technologies. So when you switch a technology, you will only see the DRC script related to this technology in the Tools/DRC list of DRC scripts.

  And finally regarding 3.)

  "output" is kind of idiot proof

  KLayout will see there is a new layer and add it to the layer list if there is no such layer - styling is up to you then. If you're generating GDS by writing to a file with "target", the layer is simply there.

  Don't output to a layout you have declared for input before - KLayout might crash in this case as you pull away the inputs to following operations. But you can output to a layer and then use it as input.

  If you output a layer to the same layer again, the second output will replace the first one.

  Best regards,

  Matthias