dune : SST component wrapper for ngspice

Introduction

The goal of Dune is to connect the traditional NGSpice simulation environment to the Sandia Structural Simulation Toolkit (SST). SST is a parallel discrete event simulation (PDES) infrastructure that provides developers the ability to construct architecture simulations using composable sets of simulation components. The Dune component is designed to connect the NGSpice (library build) to adjacent simulation components.

Getting Started

Prerequisites

The following packages are required to build and use Dune:

• NGSpice built in "library" mode. Aka: ./configure --with-ngshared (currently tested with 45.2)
• CMake 3.19+
• Sandia Structural Simulation Toolkit (SST) 15.1+

Building

Dune requires CMake to build the infrastructure. The build environment assumes that the SST infrastructure is in the current path and the installation location can be specified at build time. An example of doing so is as follows (from the dune source directory):

mkdir build
cd build
cmake -DNGSPICE/path/to/ngspice ../
make
make install

Testing

Dune has a built-in test harness that can be enabled during the CMake stage using:

cmake -DNGSPICE=/path/to/ngspice -DDUNE_ENABLE_TESTING=ON ../

Assuming that the build and install is successful, users can execute the test harness using:

make test

Running Simulations with Dune

Simulations using Dune can be configured using the standard set of SST SDL files (Python or JSON). An example of doing so with Python is as follows.
Additional information can be garnered via sst-info dune.Dune.

analog1 = sst.Component("test1", "dune.Dune")
analog1.addParams({
    "verbose" : 5,
    "clockFreq" : "1GHz",
    "netlist" : "test1.net"
})

Contributing

We welcome outside contributions from corporate, academic and individual developers. However, there are a number of fundamental ground rules that you must adhere to in order to participate. These rules are outlined as follows:

• By contributing to this code, one must agree to the licensing described in the top-level LICENSE file.
• All code must adhere to the existing C++ coding style. While we are somewhat flexible in basic style, you will adhere to what is currently in place. This includes camel case C++ methods and inline comments. Uncommented, complicated algorithmic constructs will be rejected.
• We support compilaton and adherence to C++ standard methods. All new methods and variables contained within public, private and protected class methods must be commented using the existing Doxygen-style formatting. All new classes must also include Doxygen blocks in the new header files. Any pull requests that lack these features will be rejected.
• All changes to functionality and the API infrastructure must be accompanied by complementary tests All external pull requests must target the devel branch. No external pull requests will be accepted to the master branch.
• All external pull requests must contain sufficient documentation in the pull request comments in order to be accepted.

License

See the LICENSE file

Authors

• John Leidel
• David Donofrio
• Tim Dysart

Acknowledgments

This work was supported by the U.S. Department of Energy, Office of Science, Advanced Scientific Computing Research program under project 84245—Democratization of Co-design for Energy-Efficient Heterogeneous Computing (DeCoDe) at Pacific Northwest National Laboratory (PNNL). PNNL is a multi-program national laboratory operated for the U.S. Department of Energy (DOE) by Battelle Memorial Institute under Contract No. DE-AC05-76RL01830.