PCell: Hidden vs. Visible parameter behavior

cbourde

Hi,

I'm using KLayout 0.27.4 on a Windows 10 machine. I'm building a PCell using Ruby and observing some behavior with hidden parameters I don't expect/understand - I'm hoping someone more familiar with these topics could weigh in. The ruby code I'm running in the Macro environment is shown below.

module TEST_PCELLS

  include RBA
  TEST_PCELLS.constants.member?(:PC1) && remove_const(:PC1)

  class PC1 < PCellDeclarationHelper
    include RBA
    def initialize
      super
      param(:l1, TypeLayer,  "Layer",   :default => LayerInfo::new(1, 0), :hidden => true)
      param(:v,  TypeDouble, "Visible", :default => 1.0)
      param(:h,  TypeDouble, "Hidden",  :default => 2.0, :hidden => true)
    end

    def display_text_impl
      str = "V=#{'%.1f' % v.to_f} H=#{'%.1f' % h.to_f}"
    end

    def coerce_parameters_impl
      puts "1: Visible[%.1f], Hidden[%.1f]" % [v, h]
      if v != h
        puts "2: Visible[%.1f] != Hidden[%.1f]" % [v, h]
        set_h v
        puts "3: Visible[%.1f] != Hidden[%.1f]" % [v, h]
      end
      puts "4: Visible[%.1f], Hidden[%.1f]" % [v, h]
      puts " "
    end

    def produce_impl
      dbu     = layout.dbu
      box = RBA::Box::new(0, 0, h/dbu, 1/dbu)
      cell.shapes(l1_layer).insert(box)
    end

  end

  class TPC_LIB < Library
    def initialize  
      self.description = "Test PCell Library"
      layout.register_pcell("PC1", PC1::new)
      register("TPC_LIB")
    end
  end

  TPC_LIB::new

end

After running this script within the Macro Development environment, adding an instance into a new layout and edit the PCell parameters, I observe the following in the output console:

1: Visible[3.0], Hidden[3.0]
4: Visible[3.0], Hidden[3.0]

1: Visible[4.0], Hidden[3.0]
2: Visible[4.0] != Hidden[3.0]
3: Visible[4.0] != Hidden[4.0]
4: Visible[4.0], Hidden[4.0]

1: Visible[4.0], Hidden[3.0]
2: Visible[4.0] != Hidden[3.0]
3: Visible[4.0] != Hidden[4.0]
4: Visible[4.0], Hidden[4.0]]

The 1st two lines show up when I open the Object Properties dialog box, no questions here. When I change the visible parameter value from 3 to 4, I observed the next 4 lines which show the if statement being triggered in the coerce_parameters_impl block, this should set the hidden parameter to the same value as the visible parameter and indeed it appears to be doing that when you compare line 3: and line 4: output strings. What I don't understand is why I observe the last block of 4 lines which suggest to me the if statement was triggered a 2nd time... how did the hidden parameter get set back to 3.0? If I remove the :hidden => true from the h parameter, I observe what I'm expecting, a single pass through the if statement, console output below:

1: Visible[4.0], Hidden[4.0]
4: Visible[4.0], Hidden[4.0]

1: Visible[3.0], Hidden[4.0]
2: Visible[3.0] != Hidden[4.0]
3: Visible[3.0] != Hidden[3.0]
4: Visible[3.0], Hidden[3.0]

1: Visible[3.0], Hidden[3.0]
4: Visible[3.0], Hidden[3.0]

Any thoughts on why I'm observing this behavior with hidden parameters?

Thanks in advance!

Matthias

@cboude I'm afraid there is no true explanation.

Please consider the PCell "stateless". This means, there is no warranty which state the PCell is in or when certain methods are called. KLayout will cache PCell evaluation results, hence it may call coerce_parameters_impl less times than you expect. On the other hand it may call it more often, because it may update instances left in the cache without you seeing it. Maybe methods are called twice - maybe those are stray Qt signals triggering that.

If you want to know the details you need to study the C++ code. But I assume that is tedious and there is no warranty it will stay exactly that way, so my advice is to use coerce_parameters_impl what it is intended for: normalize the parameters, so they will fulfil constraints you impose (e.g. apply a limit to a maximum value). Another application is to utilize hidden parameters to implement a PCell state.

"coerce_parameters_impl" is not an edit callback if you're trying to achieve that. It may be possible to suppress the second pass you mention, but there is not warranty overall that this can never happen.

Matthias