# PTBehavioral

`PTBehavioral` is the parse-tree node for a behavioral source instance - the `name (n1 n2) v=expr` / `i=expr` shorthand ([Parser](dflparser.md)'s `behavioral` rule) for describing a two-terminal source directly by a potential or flow (current) equation, without hand-writing a Verilog-A module. It stores an instance name, a [`PTIdentifierList`](ptidentifier.md) of terminal connections (expected to be exactly two - `ParserTables::processBehaviorals()` rejects anything else with `Status::BadArguments`, the type itself does not enforce it), the compiled [`Rpn`](rpnexpr.md) expression, a `currentSource` flag (`true` for `i=`/`flow=`, `false` for `v=`/`potential=`), and the target discipline plus potential/flow accessor names - `"electrical"`/`"V"`/`"I"` unless overridden by a constant `discipline=(name, potAcc, flowAcc)` parameter. Like most types here it's move-only; `verify()` is a no-op placeholder that always returns `true` - there is nothing to check about a `PTBehavioral` on its own, since real validation happens when it is turned into Verilog-A.

[`PTBlock`](ptblock.md) holds a vector of `PTBehavioral` alongside its models and instances, and [`PTSubcircuitDefinition`](ptsubckt.md) forwards `add(PTBehavioral&&)` into its root block, the same way it forwards `PTModel`/`PTInstance`.

[`ParserTables::processBehaviorals()`](parsertables.md) is what actually consumes them: it calls `Rpn::verilogA()` (see [Expression Format](rpnexpr.md)) to translate each `PTBehavioral`'s expression into a generated Verilog-A module, captured in an `RPNBehavioralVA` (declared in `rpnexprva.h` - the parameters, potential nodes, and flow/branch pseudo-terminals the generated module needs, plus its name and source code). The generated module's source is appended to one accumulated `.va` file for the whole netlist; a matching `PTModel`/`PTInstance` pair is added to the same block, bound to that module, with the instance's parameters wired as pass-through expressions from the original behavioral's own parameter references, and its terminal list built from the two original connections plus one per potential node the generated module needs (flow/branch pseudo-terminals are connected later, during hierarchical elaboration, not at this stage). The generated `PTInstance` keeps its `RPNBehavioralVA` attached via `addBehavioralData()`/`behavioralData()` (see [`PTModel and PTInstance`](ptmodel.md)), so later code can still see how the generated module maps back to the source expression.
