Ctrl+K

Models

Models#

piel provides a component model library to aid co-simulation. However, to extract a range of system performance parameters, simulations often tend to have to be done in different domains. This is why we need to have models that represent the same component, in different domains.

Domains#

Multiple physical domains need to be understood of a system to create an optimal interconnection implementation. We provide a set of component models in multiple domains, that can be easily interfaced with each corresponding domain simulator.

Models are provided in the following types:

Types of Descriptions and Examples#

Type

Description

Examples

Frequency

Frequency domain relating inputs and outputs.

Logical

Deterministic relationships from a defined input to an output that implement a logical operation.

Physical

Relationships between physical parameters and other physical performance parameters.

Waveguide width vs optical attenuation per meter vs TE mode.

Time

Transient domain models of time-dependent state changes.

Time Domain#

It is important to note that optical time may not be in sync to electronic time. This means that optical signals vary and change independently of electronic signals. Fundamentally, this means that electronic-photonic systems are interconnected but can be operating at different clock rates, and both electronic and photonic functions depend on both the inputs of both electronic and photonic systems.

Actual operations are combined and need to be treated as mixed systems, they can not be considered independently because on its own that does not represent a useful output.

We can now simulate SPICE-based circuits alongside ourdefined layout electrical models. This allows us the power to implement our own sources, and our own components in a more complete manner. However, this does not fundamentally solve the problem we have on multiple time domain simulations. We have timing data from digital sources and analog electronic sources. If you have delayed photonic signals, then we also have timing data independently in the photonic domain. This leads to a major time-synchronisation issue. It is in this type of problem structure that a microservice implementation again comes to the rescue.

For example, digital signals are particularly valuable and useful when considering steady-state signal propagation. Analogue signals are particularly interesting in the transition between electronic states, as the rise-times and signal-shapes will be determined by RC constants primarily. In the midst of all of this, photonic signals can change independently. There is a direct control from the electronics to the unitary of the component, and at discretised points in time the unitary can be computed. For the period of discrete time this signal is valid, the unitary can be computed. The accuracy desired is just determined by the discretization time. In that period of time, there is a linear relationship between optical signal inputs, and outputs.

As an approximation, if the signals are switching between logic levels, then it is reasonable to compute the analog rise-time and fall-time signals accordingly and operate on them linearly if the digital clock period is high. However, if the logic levels in which the signal is switching is

SPICE Integration#

The implementation mechanism is to provide component models that include the raw interconnect based on similar gdsfactory port naming and matching. This will allow us to design netlists that can be closely mapped into a SPICE solver, directly from gdsfactory. This may eventually be interconnected through VLSIR.

Note that for a particular SPICE implementation, more than time-domain simulations can be performed as well. This is why piel provides functionality to construct simulations to perform these multi-domain simulations and construct these systems from component model primitives.

Model Composition with hdl21#

These functions map a particular model, with an instance representation that corresponds to the given netlist connectivity, and returns a SPICE representation of the circuit in the form of a hdl21 structure. This function will be called after parsing the circuit netlist accordingly, and creating a mapping from the instance definitions to the fundamental components.

However, each model may be reasonable for it to be a parametric generator based on the settings of the gdsfactory instance. Note that in order to not have to assign the directionality of ports it could be reasonable to use signals instead of ports. We generate this instance based on the gdsfactory port keys, although the assignment of which is an input or output is essential based on the initially parsed netlist. A generator follows the following syntax and the output module can be connected as part of a larger instantiation accordingly.

import hdl21 as h
@h.generator
def MyFirstGenerator(params: MyParams) -> h.Module:
    # A very exciting first generator function
    m = h.Module()
    m.i = h.Input(width=params.w)
    return m

The models provided are hdl21 generators based on parameters that are inputted from the instance settings for the defined set of parameters and we use the construct it from the nested dictionary:

@h.paramclass
    class Outer:
        inner = h.Param(dtype=Inner, desc="Inner fields")
        f = h.Param(dtype=float, desc="A float", default=3.14159)

    # Create from a (nested) dictionary literal
    d1 = {"inner": {"i": 11}, "f": 22.2}
    o = Outer(**d1)

So this allows us to return instance models that compose our circuit.

TODO REFERENCE EXAMPLES.

Contents