m parameter for BJT models and Xschem-symbols

[olisnr]

if i look at the ihp-sg13g2/libs.tech/xschem/sg13g2_pr/npn13G2.sym it has the parameters:
format="@spiceprefix@name @pinlist @model Nx=@Nx"

shouldnt be Nx the analog of W in the MOS-models? and m the factor for arrays of BJT?
in the MOS models there is w, l, ng, m, shouldnt in the npn13G2 be nx, m? and maybe also t?

in ihp-sg13g2/libs.tech/xyce/models/sg13g2_moshv_mod.lib there is the .subckt npn13G2

.subckt npn13G2 c b e bn 
.param Nx=1 dtemp=0
+Ny=1 le=0.96e-6 we=0.12e-6
+El=le*1e6
+selft=1

*Yvbic13_4t_va vbic1 c b e s1 npn13G2_NX_vbic
Qnpn13G2 c b e s1 t npn13G2_NX_vbic dtemp=dtemp m=1

it sets m=1 why?

i also think, its a bit sad, that the pnpMPA hasnt an m-parameter. thats the part that is normally used as m=1 and m=9 or the like.

would it be possible to add the m? (and t) parameters to the models and symbols like in the MOS-devices?

[KrzysztofHerman]

@olisnr

The Nx parameter is a number of emitters of the HBT device.

The m parameter is pretty generic in spice and it has a meaning of number of instances in parallel.
It could be useful for automatic layout generation, however causes problems in simulations like MC,
where you would like to estimate circuit behavior while varying parameters of the instances.

in the ngspice manual you can find respective BJT device instantiation scheme where the m parameter is present but not commented.

QXXXXXXX nc nb ne <ns> <tj> mname <area=val> <areac=val>
+ <areab=val> <m=val> <off> <ic=vbe,vce> <temp=val>
+ <dtemp=val>

It is curious because SPICE reference from Berkeley does not mention it.

 General form:
    QXXXXXXX NC NB NE <NS> MNAME <AREA> <OFF> <IC=VBE, VCE> <TEMP=T>

Also if you take a look at the Xyce Reference Guide 7.6 in the section 2.3.17 you will not find anything related to the m parameter

As for t it is not a parameter but an additional temperature related output. We have already provided spice models for 4 and 5 terminal devices for ngspice to have the consistency between symbols and models and a correct recognition of the terminals by the simulator. The same should be applied to the xyce HBT models

[olisnr]

yes the m is very interesting for things like bandgap references and current-mirrors.

in the Xyce Reference Guide 7.7 there a BJT models with m:
Table 2-66. Bipolar Junction Transistor Device Instance Parameter - page 246
Table 2-80. MEXTRAM 504.12.1 Device Model Parameters - page 273

In the version 7.8 there of the Xyce Users Guide there is written:

5.4.
Subcircuit Multiplier M
Similar to many device models, subcircuits support a scalar multiplier, M on the instance line. The usage
syntax is similar to that of subcircuit parameters, except that it is implicitly applied to all devices (see
table 4-3) in the subcircuit instance which support multipliers. If the devices in a subcircuit already have
multiplier parameters specified, the value is multiplied by the subcircuit instance value. This is applied
recursively for nested subcircuits.

thus i would think, that the m-parameter should be possible for all BJTs

what do You think?

[olisnr]

i mean a schematics like this shouldent be necessary :)

[KrzysztofHerman]

@olisnr it seems that the m parameter is supported by many devices and maybe this is the reason it is skipped as a default parameter. As for the feature of exposing it to the user I can see the advantage of schematic readability (although maybe it is better to see these 20 BJT's).

[olisnr]

what do You think, could we expose m in npn13g2, npn13g2l, npn13g2v & pnpMPA?
i think i can do it my self an make a pull-request, if its interesting.

[sergeiandreyev]

Hi @olisnr, regarding this

i also think, its a bit sad, that the pnpMPA hasnt an m-parameter.
would it be possible to add the m? (and t) parameters to the models and symbols like in the MOS-devices?

we're now in progress to implement a new pnpMPA device, so that all the device data is expected to be updated before integration into PDK. We can prioritize the question on the multiplier parameter

[sergeiandreyev]

what do You think, could we expose m in npn13g2, npn13g2l, npn13g2v & pnpMPA? i think i can do it my self an make a pull-request, if its interesting.

we should have consistency where possible between the OpenPDK and proprietary one, this kind of change we have to discuss first internally.. I'll update you on the results