# PTModel and PTInstance

`PTModel` is a `model <name> <device> [params]` statement: a model name, the device/master it binds to, and parameters. `PTInstance` is an instance placement: a name, its master (model or subcircuit) name, a [`PTIdentifierList`](ptidentifier.md) of terminal connections (an `Id::none` entry meaning "not connected"), and parameters. Both are move-only and both expose `isParameterized()` (any *expression* parameters, not just constant ones - see [`PTParameterValue`/`PTParameterExpression`](ptparametervalue.md)) - relevant to whatever downstream code needs to know if this model/instance requires re-evaluation when something changes, rather than being fully resolved once and for all. Their `verify(level, s)` at this level only checks their own [parameter list](ptparameters.md) for duplicates; see [`ParserTables`](parsertables.md) for what `level` actually gates.

[`PTSubcircuitDefinition`](ptsubckt.md) inherits directly from `PTModel`, reusing its name/parameters storage for a subcircuit's own identity.

`PTInstance` additionally has an optional `behavioralData_`, an owned `unique_ptr<RPNBehavioralVA>` set via `addBehavioralData()` and read back via `behavioralData()` (nullptr if absent). It is only ever populated for the auto-generated instance [`ParserTables::processBehaviorals()`](parsertables.md) creates out of a [`PTBehavioral`](ptbehavioral.md) - the `RPNBehavioralVA` (declared in `rpnexprva.h`) records how the generated Verilog-A module's parameters and potential/flow nodes map back to the original behavioral expression, and is consulted later (e.g. by `dump()`, and by hierarchical elaboration when connecting branch/flow pseudo-terminals) since an ordinary instance built directly through this API never sets it.
