Integrations

Methodology

Microservice Architecture

piel is designed to be a microservice architecture. This means that each tool is a separate service that can be run independently. This is a very powerful design pattern that allows for the development of each tool independently. It also allows for the development of new tools that can be integrated into the piel framework without having to change the existing tools.

Case Study

GDSFactory is an incredible tool for photonic, layout, simulation and design. However, for digital design, the OpenROAD design process is far more mature in terms of chip designs. We want to leverage the power of both. It is possible to design any GDS-based layout in GDSFactory and it provides a much more amenable direct-editing tool for users.

What piel is interested in is enabling the co-design between electronics and photonics. One aspect that is currently a large design challenge is exploring the effect of parametric variations on one component on a total photonic-electronic system performance. It is these design questions that piel aims to answer and simulate.

There are multiple levels of design integration of the tools. A basic set of interconnection functions is just a function that implements reading and importing the layout of the OpenROAD process directly into a GDSFactory environment.

The next level of simulation analysis is to understand the effect of the total requirements of a particular system implementation. This is already achieved through TODO LINK EXAMPLE. Each individual toolset interconnection mechanism is described on its corresponding piel/integration/<"tool1-tool2">.py source file.

cocotb - sax

This integration aims to provide an co-design mechanism for solving photonic circuit networking. One common application might be to see how a set of configured phase-shifter switches, might affect the total output of a system, and how this corresponds to the electronic function that is applied in order to drive it.

gdsfactory - SPICE Netlist - VLSIR

There are many ways in which we might desire to integrate gdsfactory with SPICE. One particular one is to be able to extract an electrical netlist from a photonic circuit, simulate the performance, and connect it to a circuit driver previously. This requires in some form extracting the port interconnection from the gdsfactory netlist, and then connecting this as part of an electronic component. This will allow us to integrate with the ngspice and xyce simulators, and in the future with Cadence and related tools.

Integration Methodology

One of the main complexities of integrating the SPICE netlist is determining the exact instance connectivity. One of the main complexities is that in GDSFactory many of these electrical components are provided in the form of cross-sectional paths. This means that we need to find a way to extract connectivity that can be translated from these fundamental structures.

This implementation follows the principle that we can build SPICE netlists out of the provided GDSFactory netlists which are port dependent. This netlist is constructed using port interconnectivity, but it is necessary to define correctly the layout of the circuit in order to get the correct interconnection and accurately generate SPICE models. To do this, we need to provide models in a very close implementation to sax. We cannot extract a SPICE interconnect without using models and using the Netlist package from Dan Friedman means we are ensuring future compatibility to VLSIR and so on. We can then perform a LVS check with the actual layout using further tools as discussed below.

LVS Tools Integration

The first step is that all GDSFactory components need to have electrical pins attached to them too, or they can not be extracted accordingly. It would be ideal for this to be performed as part of a subroutine in the layout generation scheme, like for the photonic components.

In order to extract physical electrical connectivity, then we need to make sure the pin connectivity is included in between metal layers, and that VIAs allow for connectivity between layers. This needs to conform to the standard in tools such as Cadence. In this tool, the pin process is a different purpose than the drawing layer. I can see in the generic PDK the WG_PIN layer it was already set to purpose 10 so maybe stick with it for the standard.

qutip - sax

One interesting relationship to explore is how a particular extracted unitary from a photonic network affect the quantum states (such as photons) it operates upon. This is the main motivation for integrating qutip and sax.

We provide an example of this integration here:

Conversion Assumptions

There are a list of assumptions that the user must be aware when converting in between different modelling regimes.

Quantum Information Basics

Properties of unitary matrices:

Unitary Properties

Unitary Property	Notation
Unitary	\(U^\dagger U = I\)
Normal	\(U U^\dagger = U^\dagger U = I\)
Invertible	\(U^\dagger = U^{-1}\)
Unit Eigenvalues	\(\| \lambda \| ^2 = 1\)
Length Preserving	\(\langle U \psi \rangle = \langle \psi \rangle\)

Properties of Hamiltonian matrices:

Hamiltonian Properties

Unitary Property	Notation
Hermitian	\(H^\dagger = H\)
Normal	\(H H^\dagger = H^\dagger H\)

• piel.integration
  • Subpackages
    • piel.integration.gdsfactory_hdl21
      • Submodules
        • piel.integration.gdsfactory_hdl21.conversion
          • Module Contents
            • Functions
              • convert_connections_to_tuples()
              • gdsfactory_netlist_with_hdl21_generators()
        • piel.integration.gdsfactory_hdl21.core
          • Module Contents
            • Functions
              • gdsfactory_netlist_to_spice_netlist()
              • construct_hdl21_module()
        • piel.integration.gdsfactory_hdl21.utils
          • Module Contents
            • Functions
              • rename_gdsfactory_connections_to_spice()
              • convert_tuples_to_strings()
      • Package Contents
        • Functions
          • gdsfactory_netlist_to_spice_netlist()
          • construct_hdl21_module()
          • convert_connections_to_tuples()
          • gdsfactory_netlist_with_hdl21_generators()
  • Submodules
    • piel.integration.amaranth_openlane
      • Module Contents
        • Functions
          • layout_amaranth_truth_table_through_openlane()
    • piel.integration.cocotb_sax
    • piel.integration.gdsfactory_openlane
      • Module Contents
        • Functions
          • create_gdsfactory_component_from_openlane()
    • piel.integration.sax_qutip
      • Module Contents
        • Functions
          • sax_to_ideal_qutip_unitary()
          • verify_sax_model_is_unitary()
    • piel.integration.sax_thewalrus
      • Module Contents
        • Functions
          • unitary_permanent()
          • sax_circuit_permanent()
    • piel.integration.thewalrus_qutip
      • Module Contents
        • Functions
          • fock_transition_probability_amplitude()
    • piel.integration.type_conversion
      • Module Contents
        • Functions
        • Attributes
          • array_types
          • tuple_int_type
          • package_array_types
          • convert_array_type()
          • convert_2d_array_to_string()
          • absolute_to_threshold()
  • Package Contents
    • Functions
    • Attributes
      • create_gdsfactory_component_from_openlane()
      • gdsfactory_netlist_to_spice_netlist()
      • construct_hdl21_module()
      • convert_connections_to_tuples()
      • gdsfactory_netlist_with_hdl21_generators()
      • sax_circuit_permanent()
      • unitary_permanent()
      • sax_to_ideal_qutip_unitary()
      • verify_sax_model_is_unitary()
      • fock_transition_probability_amplitude()
      • array_types
      • tuple_int_type
      • package_array_types
      • convert_2d_array_to_string()
      • convert_array_type()
      • absolute_to_threshold()