Crossing auto

[jevillegasd]

Waveguide crossings tool

The waveguide crossings tool allows to .... insert waveguide crossings automatically.

• Upon calling path_2_waveguide2() if any of the selected paths intersect with one another, and a cell for a crossing has been configured in the waveguide XML file (and exists in the technology files), a user may insert a crossing cell automatically at the crossing location.
• Modifications in this merge include minor changes in the path_to_waveguide functions, a new file in SiEPIC.utils called crossings (is this the correct location??), and a change in core waveguideGUI to include the parameter 'crossing_cell' in the search for waveguide parameters. I've copied the 4crossing cell from Prof Shi (in the EBeam PDK) in the GSiP technology gds files so that the crossings functions have something to do with the generic tech by default, and modified the corresponding WAVEGUIDE.xml definition to include an example of referencing the crossing cell.

It can be tested using the attached file, to generate the other attached file: crossings.zip

Know issues

• To generate the crossing it expects that the crossing is centered
• It uses the bounding box (not the DevRec bounds) to determine the size of the crossing cell, therefore it's always slightly larger than what it needs because of the pin half_length. This normally doesn't generate any problem since the waveguides themselves will snap to the new pins upon creation.... but sometimes they don't, leaving small spaces between the waveguide and the crossing cell.
• The crossing cell needs to be square and only supports manhattan waveguides. Putting a non-manhattan crossing now generates an undefined behavior (usually just cuts the waveguide in place and leaves disconnected crossings in each crossed location)
• Does not work for most self-intersecting paths.

Also in this merge:

Update layer reading:

A small change in the reading part of the layer information, in the form of a recursive call to allow deeper structures in the layer deck. Tested against AMF_PDK and is working well (I think that's the only PDK library initialization that is using this function currently). Nested groups in the layer deck can with this be used to allow extra categorization. For example:

[mustafacc]

Hi Juan,

Apologies for the delay - I forgot to address this pull request. This is a very useful feature. I'm trying to implement this in the EBeam_PDK and I'm not seeing the expected crossings in your example file.

The main change that I made to the PDK is that I added a definition in the waveguides.xml to include a parameter. I have included this definition in the EBeam_PDK waveguides.xml. (on that note: can you include a definition as well? similar to compound waveguides>

Is there anything else that I need to change?

[jevillegasd]

Hey @mustafacc , sorry I was disconnected for the past month. Yes that should be the only change needed, let me check if this is still working with the latest release of SiPEIC tools or if anything else is needed.

[lukasc-ubc]

Thanks Juan! Indeed, a useful feature. I believe the GSiP PDK hasn’t been tested for a while so might need some fixing / upgrading.

[jevillegasd]

Hey @mustafacc it should be working now. In the Waveguide XML, you need to include any of the following:

For a complete definition of library and cell offset:

<crossing>
        <crossing_cell>ebeam_crossing4</crossing_cell>
        <crossing_library>EBeam</crossing_library>
        <crossing_offset>(0,0)</crossing_offset>
</crossing>

Or you can also just add the cell name, in which case the script will assume it is part of the current technology

<crossing_cell>ebeam_crossing4</crossing_cell>

I've udptaded this commit to the current version of SiEPIC tools, so it should work fine (I've tested it for both GSiP and EBeam)

[lukasc-ubc]

lovely!