Does chip has to be a macro?

[srjmas]

While I find your Elements Library PCells very useful, I do not see the benefits of developing chips as macros. Chip frame, pads, markers and masks are all fairly static designs that are easily maintained in a classical static cells way, as a GDS hierarchical cells library. Creating them programmatically has on the other hand the disadvantage of using a non-visual tool for a visual design, slowing the process. Am I missing something, is there a good reason to develop my chips as macros? In particular in regard with pyEPR integration,

[jheinsoo]

In KQC, chips are not macros but Elements. This means there is code which can add PCells (parameterized Cells) into KLayout PCell library. This is useful if you want to study many variants of the same design systematically. For example, you might study the capacitance between qubit and coupler as a function of the coupler geometry. Making a systematic sweep of the coupler size in my humble opinion is not feasible manually. Later, one might want to generate variants of the same chip with different geometrical parameters; for example different coupler sizes between qubits for different two qubit gate speeds. Only way to be systematic, is to have things well reproducible and to be clear about the relations between parameters and geometry. Traditional CAD tools achieve this with very complex GUI features and do not represent the definition between the relations in a clear way - one usually dimension relations in the end as a table as a part of the drawing.

Now macro can be used to place Elements or PCells into your Layout in a programmatic way, but you do not need to use Macros for that. You can use GUI. You can use GUI to build a chip, you do not need to define an Chip Element programmatically. You can then save the file in any format KLayout supports. KLayout can also embed the parameters of the PCells into the exported file so you do not need to turn exported elements into static cells (loosing the parametrization of the Elements you used). You can also use macro which generates a simple python code out of PCells in your layout which you can use as a starting point to turn your chip definition into code.

[srjmas]

Thank you for your detailed replies.

1. After creating my chip layout in a GUI and saving as GDS/OASIS, possibly with PCells parameters, how can I integrate it back into the mask creation workflow? i.e, what should I write in the mask creation macro instead of the from kqcircuits.chips.chip import Chip?
2. For simulation purposes, will I be able to access some of the GUI-made chip parameters programmatically, to perform a sweep?

[caspar-iqm]

I'll try to answer these questions, but let me know if I understood the questions wrong :)

1. The example mask script m001.py contains example code for including a chip from an OAS file. Here, m001 is a MaskSet instance:

qdd = m001.load_cell_from_file(file_name)
m001.add_chip(qdd, "QDD")

Normally we use this method for static cells (for example if we want to include an older version of a chip on a newer mask). If you have PCells in the OAS file it should work fine, but note that KLayout always regenerates the PCells when loading the file.

2. If chip is stored as PCell, it is indeed possible to write a script that updates the parameters using change_pcell_parameters. However this requires a bit of extra coding, probably it's easier to do sweeps programatically.

[srjmas]

Thank you,

1. m001.py example of loading chip from file seems to work, but for now I think I will stick to manual mask design - with the Klayout binary layer utils the overhead is not that big for our 10mm chips on 2" wafers.
2. It is good there is the option to work with a design file as input, however by this point it is a game of trial and error to see which approach works best in a particular case. When I will get there I will update here.

[nikosavola]

In addition to the 'regular' workflow of analysing a single geometry with a pyEPR notebook, one can write scripts (or notebooks) to save the relevant data from pyEPR and sweep over these programmatically-made GDS files. It's a matter of preference and how much scaling is needed.

For a GUI workflow, something like export_ansys.lym may be used with

simulation = Simulation.from_cell(top_cell, margin=100, name=name)

and adjusting the simulation ports as desired. Afterwards, the regular export as in xmons_direct_coupling_pyepr.py should work.

[srjmas]

Thank you. PyEPR parametric sweep is indeed a very valid argument for the sake of code to layout workflow. I wonder however (as mentioned to jheinsoo) if there is some easy way to perform a parametric sweep on a CAD developed design, allowing to enjoy both worlds