Models and Technology¶

Monata treats models as part of the design environment. A library records the model paths and technology assumptions that its cells are expected to use.

Ownership Boundaries¶

Model and process metadata has more than one storage surface. Treat each surface as owning one layer:

Surface	Owns	Does not own
Library `lib.toml`	Library design context: static model paths, simulator preference, attached techlibs, and a default corner name	Project-local compiled artifacts
Techlib `techlib.toml`	PDK/process policy: device cells, views, model decks, supported corners, nominal voltage, and device defaults	Per-project experiment assets
Project `models.toml`	Project-local model artifacts: OSDI paths, Verilog-A source paths, include files, `.lib` sections, and device metadata	PDK/process policy
`SimTask`	One-run execution inputs: explicit `corner`, `osdi_paths`, `param_overrides`, outputs, simulator, and metadata	Reusable technology policy
Netlist model directives	Concrete include/lib statements for execution, or Monata logical model refs for generated artifacts	Techlib discovery or corner selection

Resolution Precedence¶

When more than one layer can provide model context, use this order:

Explicit SimTask inputs and concrete netlist directives apply to that single run.
Library attachments and an explicit or default corner select the techlib projection context for generated PDK-backed devices.
Techlib metadata materializes the selected corner into concrete model deck, section, source voltage, and device-default data.
A project models.toml manifest contributes artifacts only when user code resolves it and applies the resulting ModelSelection or osdi_paths.
Legacy library technology.model_paths are static model-card paths for simple library flows; they are not a replacement for techlib corner policy.

This keeps reusable process policy in techlibs, experiment-local artifacts in the project manifest, and one-off execution overrides in the simulation task.

Library-Level Model Paths¶

Model paths belong in lib.toml:

[technology]
model_paths = [
  "models/ptm_45nm_nmos.lib",
  "models/ptm_45nm_pmos.lib",
]
simulator = "ngspice-subprocess"
node_type = "bulk"

Keep these paths close to the library so cells can share one technology configuration.

Use techlib_attachments and default_corner when the library is backed by a formal technology package:

from monata import LibraryRegistry

reg = LibraryRegistry()
lib = reg.create_library(
    path="work/cmos_cells",
    name="cmos_cells",
    techlib_attachments=["PTM_BULK"],
    default_corner="ptm65",
)

The library records the attachment; the techlib remains the owner of process and device metadata.

Model Types¶

Model type	Typical use
SPICE model cards	PTM bulk CMOS and simulator-native compact models
Verilog-A source	Deferred native model-compilation workflow
OSDI library	Precompiled Verilog-A model artifact loaded by ngspice `pre_osdi`
Simulator plugin	Deferred simulator-specific model-loading workflow

Packaged Technology Assets¶

The optional monata-techlib package keeps reusable PTM technology metadata outside the core monata package. It includes PTM model-card bundles and the minimal BSIM-CMG Verilog-A source subset needed for local PTM_MG OSDI compilation.

This package has a mixed license boundary:

Monata-authored loader code and techlib metadata are MIT licensed.
PTM model cards remain third-party model data subject to PTM attribution and no-warranty terms.
The bundled BSIM-CMG Verilog-A source subset is provided under ECL-2.0.
The package does not ship ngspice, libngspice, OpenVAF, XSPICE code models, or precompiled .osdi binaries.

Compiled OSDI outputs are local cache artifacts created only when the user enables compilation and provides the external compiler toolchain.

Choosing a Model Path¶

Use this decision path:

If the model is already supported by the backend, include the model card.
If the model is already compiled to .osdi, pass it through SimTask.osdi_paths for the native ngspice backend.
If the model is Verilog-A source and still needs compilation, track compilation as a deferred model-tooling task for now.
If the target requires simulator-specific plugin loading, track it as a deferred backend task for now.
If support is uncertain, check the compatibility reference before writing Monata code around the model.

Compiled Model Artifacts¶

Compiled model artifacts should be treated as technology assets, not as cell source files. Put them in a stable model directory and reference them from the library or netlist generation flow.

Project-local artifacts that are not part of an installed techlib should be recorded in the project model manifest:

from monata.workspace.project import Project

project = Project.open("work/my_project")
manifest = project.model_manifest()
selection = manifest.resolve(family="bsimcmg")
osdi_paths = selection.osdi_paths

The manifest is an artifact registry. It should not encode which process corner is authoritative for a reusable library; that belongs in techlib metadata and the library attachment.

Corner API Migration¶

New code should use monata.corner.OperatingCorner for both simulation operating points and process/model metadata. Public simulation and techlib modules do not expose a compatibility type named Corner; import the canonical type from monata.corner.

Use voltages in new payloads:

from monata.corner import OperatingCorner

corner = OperatingCorner(
    "ss_0p9v_125c",
    temperature=125,
    voltages={"VDD": 0.9},
    techlib="PTM_BULK",
    model_deck="ptm65",
    section="ss",
)

Legacy payloads using historical spellings should be normalized at project boundaries before new data is written. Documentation and new code should not introduce those older spellings.

For detailed compiler workflows, see:

For model family background and compatibility, see: