KLayout PCell integration

[CDaunt]

Hi

Is there any plans to offer PCell integration through KLayout rather than a static cell library?

[Ronald]

Hi CDaunt,

The short answer is: yes.

The longer answer is that PCell integration and libraries in a drag & drop environment for mask layout, e.g. in KLayout, can be very useful for beginning designers to navigate through BBs and options. Also, such environment is useful to accomplish, or experiment with, the coarse layout floor plan for any level designer. However, with a growing number of components, or with more experience with Nazca script, the scripting environment tends to become (much) more efficient than clicking your way through drag & drop menu’s. A smooth integration between both worlds is the ideal case. PCell integration in KLayout in this context is therefore a noble goal. It is within reach. The SiEPIC project, for example, already provides PCells integration in KLayout. Underpinning such concepts with Nazca netlisting and scripting capabilities will, I believe, provide an even more flexible and powerful design environment for any PIC designer.

Ronald

[CDaunt]

Hi Ronald

I do agree that scripting masks becomes more powerful for larger designs (and is how I work although admittedly not with Nazca). However, in my experience, the threshold to program (sometimes in a new language) is often too high and hinders widespead adoption in a group. Integration with PCells in Klayout would allow those who have not thought about working that way to see what is possible in an environment they are familiar with.

The SiEPIC project was exactly what I was thinking about when asking this question as it does seem quite possibly to marry the two. Looking into the code on this, it certainly seems feasible. My initial thinking is to define a class that inherits a nazca cell and the required PCellDeclarationHelper (or some subclass of it) where the method produce_impl() converts nazca elements to klayout elements. The structural problem comes from the requirement on the type being declared for the parameter input in the PCellDeclarationHelper but perhaps that could be default to the type declared in the doc string of the nazca class or something unless overwritten.

[Ronald]

Hi CDaunt,

I agree with your observations on user and technical level.
Conversion between a Nazca cell and a KLayout cell should do the trick. Nazca internally has a detailed hierarchical representation of a layout and/or circuit, which can be exported modularly to various output formats like gds, svg, png, netlist, nazca-script, etc., while collapsing (part of) the hierarchy where desired or required. I haven’t studied the KLayout elements in great detail, but my impression is that the structure is very similar. For an exchange back and forward (one way is very restrictive and frustrating in a design flow) a superset of attributes is required. I am not to worried about types for PCells, as these can be stored as attributes in an exchange/conversion. In Nazca we can keep track of parameter types and range checking. It adds some book-keeping regarding parameter type-casting and units, but that is not bad from an engineering perspective. I do not see great technical issues and think it is less of a software challenge than the right design-interface/flow choices from a designer’s perspective.

[Author]

Posts