callback_impl pass through value changes

Tabra

Hello,

I was attempting on implementing a TypeCallback clickable button + callback_impl(self, name) function to trigger changes on the parameters of a PCell with a click (for example, setting defaults/specific parameters).

When going for it, self.name = xx wouldn't work, and self.name.value=(xx) only seems works within the scope of the function callback_impl (checking the value change with print(self.name.value)).

I thought that maybe this was the intended implementation, for callback_impl to only affect the UI with enabled, readonly, visible or icon.
But then I found that using self.name.value=(xx) AND changing the state of any of the former properties, the changed value would pass through and materialize in the PCell itself.

I suppose it's a bug. An example:

def callback_impl(self,name):

if name == "callbackButton":

self.propertyName.value=(4.0)

self.propertyName.readonly = not(self.propertyName.readonly)

Thank you,
Gerard

---

P.D. I'll describe what I'm actually trying to achieve with all this, just for context purposes:

I'm trying to use libraries (static or other PCells) within a PCell so that a layout can build itself by combining these hierarchical PCells.
Segregating PCells is useful in case we want one of the building blocks for manual placement, and would also allow to implement external libraries compatible with the purpose of the PCell (maybe combining it with a metadata identifier), and still adjust the parent PCell to accommodate and perform any dependant operation for the child components.
Ideally, the PCell library would use itself to build other entries of the same library. That would be doable by calling the definition of the required PCell in another script, or external cell within the definition assuming that it's already present somewhere when executing the PCell.
This would allow to:

• Simplify PCell definitions: Split PCells into managable pieces which are easier to maintain
• Versatility: Use one of the building blocks on its own for manual designs and without redundancy
• Custom programatic grouping: Call PCells within a PCell for ease of use/convenience
• Build modifying other cells: Use PCells to convert them as static and apply further transformations
• Build on top of other cells: Perform dependant operations on the child (like booleans/fill) and add extra polygons to make a next hierarchical step PCell parent while maintaining the original instance reference
• Build with interacting cells: Smart interaction between PCells with the usage of defined relationship properties or metadata inserted into the cell

Hence I need to add any external source to a PCell and the only way I could think of is by specifying the name of the cell/pcell and look for it in embedded libraries or existing cells within the layout. The most convenient way to add one would be with a dropdown menu, but there's no TypeLayer equivalent for cells and/or library entries, and I don't know how to dynamically load the choices property of the TypeList. I assume that this is incompatible within the PCell definition as it is a segregated unit of sorts.
Then I thought, what if I execute a function that opens a custom popup with a list populated with all the existing cells and library entries of the session, for then to return the string of the selected entry? And here is where I had trouble on changing the state of a TypeString on a callback event.

Matthias

Hi @Tabra,

The value attribute inside "callback_impl" was intended to provide information about the current value to allow status change dependent on a value. Setting the value has the potential of creating a loop of callback invocations, so I would not recommend this. Maybe it's possible to implement "value setting allowed, but without further consequences". I need to check.

Regarding your architecture sketch: I'd not recommend using PCells as building blocks. This is a habit that is adopted by users of legacy systems using ancient coding paradigms, specifically the one which do not feature namespace isolation or make variables global by default.

In KLayout, PCells are just interfaces to the editor. The code behind the PCell is supposed to generate layout mainly. For this purpose you can make full use of modern languages like Python - you do not need to go the hard way and instantiating other PCells. Eventually a PCell instance is nothing more than a procedure call, maybe backed up by some caching. If you want to make use of hierarchy, you can create static cells inside your PCell "produce_impl" implementation and fill them dynamically.

To give an example: let's say you build a simple planar MOS device having contacts. You probably would like to create a contact PCell you can use both standalone (e.g. for taps), but also (with different implant) as source/drain contacts. You could build your device from some code that generates wells, poly, whatever and then places PCells for the source and drain contacts:

MOSDevicePCell -> 
  1. instantiates ContactPCell
  2. generates other layout
ContactPCell -> 
  generates layout for contacts

Or: you create a Python module, with a class, let's call it ContactGenerator that provides the service of producing the contacts. So:

MOSDevicePCell ->
  1. imports ContactGenerator
  2. uses ContactGenerator class to produce the contacts
  3. generates other layout
ContactPCell
  1. imports ContactGenerator
  2. uses ContactGenerator class to produce the contacts

Now we're talking OO architecture, not weird interfaces. Using a class instead of a PCells gives you an infinite number of options, like query methods that allow you to ask the contact generator to compute the number of contacts for a given device width. You can also establish management classes for example, that help you in aligning pieces of your devices using internal knowledge of the generators (such as reference points).

If you really want to use PCells as building blocks, note the following:

1. PCells need to be stateless. The only way you can persist information are parameters.
2. PCells are reused. Their state can only depend on parameters. Same parameters has to mean same layout.

Those are hard rules. People tried to force the system into a different behavior, but I am not supporting that path.

Matthias