Dependency Bindings

Methodology

Integration

In the case of the tool integration with existing co-simulation design flows, it could be desired to have a set of migration functions that enable easy use of the integration from a design flow based on OpenLane v1 whilst enabling porting into OpenLane v2.

A wrapper function to enable this is the openlane_migration [//]: # (TODO include openlane_migration links)

Relevant Electronic Projects

This contains a list of important open-source software that tackles some challenges or individual aspects of electronic or electronic-photonic codesign.

FPGA and Chip Design Languages

Name	Description	Status
Amaranth	Industry-supported, multi-FPGA support, larger-scale integration planned.	Early-Stage Active Development
Magma Lang	Tries to replicate Verilog syntax in Python. Hard to read.	Active Development
MyHDL	Silicon-proven python-to-silicon. Weird LGPL license.	Active Development
VLSIR	Interchange formats for chip design.	Active Development

There’s a list of awesome electronics projects compiled by the CEO of RapidSilicon.

Selection of Python-to-HDL Flow

I am currently deciding which project to integrate as part of the python-to-logic design flow. There are some cases where we might want to generate some logic from some specific logical functionality. There are several projects available, but not all with suitable enough functionality:

FPGA and Chip Design Languages

Name	Description	Status
Amaranth	Industry-supported, multi-FPGA support, larger-scale integration planned.	Early-Stage Active Development
Magma Lang	Tries to replicate Verilog syntax in Python. Hard to read.	Active Development
MyHDL	Silicon-proven python-to-silicon. Weird LGPL license.	Active Development

I think going with Amaranth makes sense.

gdsfactory

GDSFactory is an incredibly complete design package with very active development. The focus of implementing a gdsfactory microservice in piel is to provide translation functions specific to common methdologies in the codesign tools used by piel. Similar functions may be required by others depending on their design flow, but these are the defaults for piel.

• piel.tools.gdsfactory
  • Submodules
    • piel.tools.gdsfactory.netlist
      • Module Contents
        • Functions
          • get_matched_ports_tuple_index()
          • get_input_ports_index()
    • piel.tools.gdsfactory.patch
      • Module Contents
        • Functions
          • straight_heater_metal_simple()
  • Package Contents
    • Functions
      • get_input_ports_index()
      • get_matched_ports_tuple_index()
      • straight_heater_metal_simple()

openlane

v1/v2 Migration

Currently, OpenLane v1 is integrated into the project whilst Openlane v2 is still in development.

OpenLane v2 designs do not have to be stored in a particular $OPENLANE_ROOT/design directory, and are a lot more flexible in terms of the design implementation and hardening. When performing parametric analysis, copying folder and generating multiple configurations may still be desired. However, because of the mess it can become to maintain multiple functions throughout the migration, some functionality is repeated for the sake of mantainability except when explicitly functions can be shared. This is in the case of internal functionality.

• piel.tools.openlane
  • Subpackages
    • piel.tools.openlane.parse
      • Submodules
        • piel.tools.openlane.parse.run_output
          • Module Contents
            • Functions
              • filter_timing_sta_files()
              • filter_power_sta_files()
              • get_all_timing_sta_files()
              • get_all_power_sta_files()
        • piel.tools.openlane.parse.sta_rpt
          • Module Contents
            • Functions
              • calculate_max_frame_amount()
              • calculate_propagation_delay_from_timing_data()
              • calculate_propagation_delay_from_file()
              • configure_timing_data_rows()
              • configure_frame_id()
              • filter_timing_data_by_net_name_and_type()
              • get_frame_meta_data()
              • get_frame_lines_data()
              • get_frame_timing_data()
              • get_all_timing_data_from_file()
              • read_sta_rpt_fwf_file()
        • piel.tools.openlane.parse.utils
          • Module Contents
            • Functions
              • contains_in_lines()
              • create_file_lines_dataframe()
              • get_file_line_by_keyword()
              • read_file_lines()
      • Package Contents
        • Functions
          • filter_timing_sta_files()
          • filter_power_sta_files()
          • get_all_timing_sta_files()
          • get_all_power_sta_files()
          • calculate_max_frame_amount()
          • calculate_propagation_delay_from_file()
          • calculate_propagation_delay_from_timing_data()
          • configure_timing_data_rows()
          • configure_frame_id()
          • filter_timing_data_by_net_name_and_type()
          • get_frame_meta_data()
          • get_frame_lines_data()
          • get_frame_timing_data()
          • get_all_timing_data_from_file()
          • read_sta_rpt_fwf_file()
          • contains_in_lines()
          • create_file_lines_dataframe()
          • get_file_line_by_keyword()
          • read_file_lines()
  • Submodules
    • piel.tools.openlane.defaults
      • Module Contents
        • test_spm_open_lane_configuration
        • test_basic_open_lane_configuration_v1
        • test_basic_open_lane_configuration_v2
        • example_open_lane_configuration
    • piel.tools.openlane.migrate
      • Module Contents
        • Functions
          • get_design_from_openlane_migration()
    • piel.tools.openlane.utils
      • Module Contents
        • Functions
          • extract_datetime_from_path()
          • find_all_design_runs()
          • find_latest_design_run()
          • get_gds_path_from_design_run()
          • get_design_run_version()
          • sort_design_runs()
    • piel.tools.openlane.v1
      • Module Contents
        • Functions
          • check_config_json_exists_openlane_v1()
          • check_design_exists_openlane_v1()
          • configure_and_run_design_openlane_v1()
          • configure_flow_script_openlane_v1()
          • configure_parametric_designs_openlane_v1()
          • create_parametric_designs_openlane_v1()
          • get_latest_version_root_openlane_v1()
          • get_design_directory_from_root_openlane_v1()
          • read_configuration_openlane_v1()
          • write_configuration_openlane_v1()
    • piel.tools.openlane.v2
      • Module Contents
        • Functions
          • get_all_designs_metrics_openlane_v2()
          • read_metrics_openlane_v2()
          • run_openlane_flow()
  • Package Contents
    • Functions
      • get_design_from_openlane_migration()
      • extract_datetime_from_path()
      • find_all_design_runs()
      • find_latest_design_run()
      • get_gds_path_from_design_run()
      • get_design_run_version()
      • sort_design_runs()
      • check_config_json_exists_openlane_v1()
      • check_design_exists_openlane_v1()
      • configure_and_run_design_openlane_v1()
      • configure_parametric_designs_openlane_v1()
      • configure_flow_script_openlane_v1()
      • create_parametric_designs_openlane_v1()
      • get_design_directory_from_root_openlane_v1()
      • get_latest_version_root_openlane_v1()
      • read_configuration_openlane_v1()
      • write_configuration_openlane_v1()
      • filter_timing_sta_files()
      • filter_power_sta_files()
      • get_all_timing_sta_files()
      • get_all_power_sta_files()
      • calculate_max_frame_amount()
      • calculate_propagation_delay_from_file()
      • calculate_propagation_delay_from_timing_data()
      • configure_timing_data_rows()
      • configure_frame_id()
      • filter_timing_data_by_net_name_and_type()
      • get_frame_meta_data()
      • get_frame_lines_data()
      • get_frame_timing_data()
      • get_all_timing_data_from_file()
      • read_sta_rpt_fwf_file()
      • contains_in_lines()
      • create_file_lines_dataframe()
      • get_file_line_by_keyword()
      • read_file_lines()
      • get_all_designs_metrics_openlane_v2()
      • read_metrics_openlane_v2()
      • run_openlane_flow()

cocotb

One of the main benefits of integrating well supported open-source EDA design tools is the potential tools integration options this enables.

cocotb is closely integrated with many HDL and Verilog-A simulators, which allows piel to directly create a link between these tools and GDSFactory and related photonic design tools. Some simulators that can be integrated accordingly are:

• Cadence Xcelium and Verilog-A via cocotb simulator support.

• ModelSim

• QuestaSim

• GHDL

Useful Commands

cocotb is an incredible tool for logical time-dependent digital systems verification. What we aim to do is extend it to interconnect out photonic models according to the electronic signals applied. There are a few useful commands worth noting:

Verilog Top-Module Device Commands

Description	Command
Get the dut, the Verilog top-module device under test.	dut
Get a list of the dut signals, modules and user-defined parameters accessible through dot notation.	dir(dut)
Get a signal value within the top level at a particular subroutine time.	dut.<"signal">.value
Get the current simulation time.	cocotb.utils.get_sim_time()

One thing we would like to do is directly connect the time-domain digital simulation data to the inputs of the photonic network performance. It is possible to access the signal data at any point using the dot notation and the subroutine desired in cocotb. This is why, while cocotb will enable writing and reading vcd standard waveform files such as those that can be inputted into GTKWave and similar viewers, the main examples of the co-design between electronics and photonics will not use this scheme. Another microservice could be implemented should a user desire.

It is desired to save the corresponding data in a much easier to use format in order to easily plot the waveforms and optical signals through a common python plotting tool. You can see how to save data into a pandas DataFrame file in docs/examples/designs/simple_design/simple_design/tb/test_adder.py. TODO link.

• piel.tools.cocotb
  • Submodules
    • piel.tools.cocotb.core
      • Module Contents
        • Functions
        • Attributes
          • check_cocotb_testbench_exists()
          • configure_cocotb_simulation()
          • delete_simulation_output_files
          • run_cocotb_simulation()
    • piel.tools.cocotb.data
      • Module Contents
        • Functions
        • Attributes
          • get_simulation_output_files
          • get_simulation_output_files_from_design()
          • read_simulation_data()
          • simple_plot_simulation_data()
  • Package Contents
    • Functions
    • Attributes
      • check_cocotb_testbench_exists()
      • configure_cocotb_simulation()
      • delete_simulation_output_files
      • run_cocotb_simulation()
      • get_simulation_output_files
      • get_simulation_output_files_from_design()
      • read_simulation_data()
      • simple_plot_simulation_data()

sax

Implementation Principle

The methodology of interconnection between photonics and electronics design can be done in the time and frequency domain. However, one of the most basic simulation implementations is determining how an electronic system implements a photonic operation. This means, for a given mapping between an electronic signal to a photonic one, how does the full photonic system change?

This is where frequency domain solver tools like sax come into play for photonics.

One pseudo electronic-photonic simulation currently available has been demonstrated in PhotonTorch 09_XOR_task_with_MZI. We want to extend this type of functionality into a co-design between electronic and photonic tools.

Pseudo-Static Active Models

One of the main principles of sax is that we can create models that allow us to simulate the frequency-domain response of the input and output. In our case, as we want to simulate the interface of electronics and photonics, we want models that we can see how the input-output varies based on the electrical signal control provided. However, as sax is a frequency-domain solver, we can not just implement time-dependent active control.

The first implementation proposed in piel is a pseudo-static implementation of sax models, whose model evaluation is dependent on a set of controlled-phase parameters for a physical circuit. This can be then interconnected with the asynchronous electrical models in cocotb through some analog or digital signal-to-phase mapping.

Another aspect that we want to make sure we are modelling is the variability of each of our interconnected photonic and electronic components. Not all photonic electro-optic phase shifters are the same, neither are the electronic drivers, neither are the bends, or multi-mode waveguides, or so on. Each can be different.

GDSFactory is a functional implementation of circuit design and physical parameterised devices can be easily created.

Implementation

A sax circuit is a “component model function” such as the ones we define for our instances. This means that we can functionally evaluate variations in our parameters by just evaluating the sax circuit function with our component parameters. This evaluation tends to be in the order of ms whereas the circuit composition tends to be in a larger order of magnitude depending on complexity. In sax documentation words:

The circuit function just creates a similar function as we created for the waveguide and the coupler, but instead of taking parameters directly it takes parameter dictionaries for each of the instances in the circuit. The keys in these parameter dictionaries should correspond to the keyword arguments of each individual subcomponent.

API

• piel.tools.sax
  • Submodules
    • piel.tools.sax.netlist
      • Module Contents
        • Functions
          • address_value_dictionary_to_function_parameter_dictionary()
          • compose_recursive_instance_location()
          • get_component_instances()
          • get_netlist_instances_by_prefix()
          • get_matched_model_recursive_netlist_instances()
    • piel.tools.sax.utils
      • Module Contents
        • Functions
        • Attributes
          • get_sdense_ports_index()
          • sax_to_s_parameters_standard_matrix()
          • snet
  • Package Contents
    • Functions
    • Attributes
      • address_value_dictionary_to_function_parameter_dictionary()
      • compose_recursive_instance_location()
      • get_component_instances()
      • get_netlist_instances_by_prefix()
      • get_matched_model_recursive_netlist_instances()
      • get_sdense_ports_index()
      • sax_to_s_parameters_standard_matrix()
      • snet

SPICE

Most photonic components are commonly driven from analogue signals that represent electrical-optical signal conversion. It is necessary to represent these analogue signals before they can be digitised. The analogue electrical load effects need to be considered as well, otherwise, circuits implemented in these tools will inaccurately measure signal transfer between domains.

Another objective of implementing this tool is to enable a clear driver-load-measurement relationship between electronic circuitry and photonic systems. We can integrate SPICE solvers with other open source tools to solve photonic computational functions and more.

Part of the objective of piel is to be as integrable as possible, and as modular as possible, because the maintainers believe this ensures longer-term usefulness than monoliths.

Integration Scheme

In piel, the SPICE-generated circuits will always be raw SPICE rather than using a package to create a circuit model or related. This is because any serious SPICE program will always accept raw inputs that can be integrated into its solvers. This will allow us in the future to integrate with SPECTRE and other related programs.

List of Relevant SPICE Projects

There are a large amount of open-source SPICE solvers currently available. In piel, hdl21 has been integrated first because it is a great piece of software and very simple to install. It is easily integrated into the IIC-OSIC-TOOLS, which means that if users install this environment, they will already be capable of using this tools with this project when installing piel. However, there are other open-source solvers that may be desired to be integrated, or even proprietary ones such as Cadence spectre and more.

We list some here for reference, and further development is welcome to integrate these in the design flow:

Electronic Circuit Simulators

Name	Description	Status
NGSPICE	Open source spice simulator for electric and electronic circuits	Active
PYSPICE	Simulate electronic circuit using Python and the Ngspice / Xyce simulators	Inactive
XYCE	Open source, SPICE-compatible, high-performance analog circuit simulator	Active
QUCS	Quite Universal Circuit Simulator, Inactive Mostly, some PySPICE Integration	Inactive Mostly

hdl21 Selection

Note that PYSPICE despite being recently inactive, already has working bindings to ngspice and XYCE, which one would think makes it suitable for python-based integration, rather than attempting to write this on our own.

The benefit of integrating pyspice is that it already has a range of built-in functionality for circuit and signal analysis, that can be easily ported into piel and integrated into the codesign process.

Note that pyspice is a a OOP-based project, which means that class-based functionality is prevalent when implementing simulations and systems, these are fundamentally run within the integration functions.

However, in practice, after an initial attempt to integrate PySPICE, it is evident how the lack of support of the project makes it difficult to integrate it into the piel project. The class typing is very archaic and it was written before pydantic data validation was a thing. Also, even if we wanted to integrate new functionality, it is likely the project would not be fully supported. It is because of this that hdl21 has been selected, as it is a well structured project with easy integrations and will be part of the VLSIR ecosystem.