wrong BJT fitting with spice model vs SP file

[scordilis]

hi,
I'm trying to get back to the latest version of qucs. I'm trying to check if it is working properlly or not to start new design on qucs or not.

the idea:
retrieve from NXP the SP file of a BFU730 @2v,10mA
then I'm using the BFU730 spice model to rebuilt a sbkt in qucs to represent the die and its package. then I'm trying to inject the correct current to have the 10 mA over 2V.

it does not fit ?
by the way do anyone knows why I do have such message with a manufacturer model :

WARNING: Unphysical model parameter Nf = 0.9926 in BJT bjt_BFU730F.BJT1.BFU610F_die_1
WARNING: Unphysical model parameter Nr = 0.98 in BJT bjt_BFU730F.BJT1.BFU610F_die_1
WARNING: Unphysical model parameter Vtf = -17.68 in BJT bjt_BFU730F.BJT1.BFU610F_die_1

I'm facing the same issue as the one faced in 2006 on the BFG425 in the workbook ...

LNA_BFU730_prj.zip

due to some issue using the latest version on linux, I'm using the win version 0.0.19 to have the DC and SP sweep working.

[felix-salfelder]

quoting from qucsator/src/components/devices/bjt.cpp

 /* Originally Vtf was expected to be PROP_POS_RANGE, but there are models
  * which use negative values. Instead of failing, warn the user.
  * \todo Provide a way to silece such warnings
  */
 nr_double_t Vtf = getPropertyDouble ("Vtf");
 if (Vtf < 0.0) {
   logprint (LOG_ERROR, "WARNING: Unphysical model parameter Vtf = %g in "
        "BJT `%s'\n", Vtf, getName ());
 }

my first impression is, that negative Vtf is not supported there. (i am not a bjt expert.)

can you please provide a slightly simpler example that shows the issue, ideally just netlist.txt and your (expected and actual) output?

thanks

[guitorri]

Not sure if there is a distinction between LOG_ERROR and LOG_WARNING.
See here the last change, follow the link on the description for further info: b3c3a59ea18.
The accepted range for Vtf was changed from positive to any range, but the warning is still issued.
I don't think that would impact your model, because it would not accept it before the change.
Maybe the issue is elsewhere (I did not run your model to see the fitting mismatch)

[scordilis]

I'll do a simplier model ... I'll dig into the bjt.cpp to understand how the Vtf is used. But still the manufacturer are using it ...

[guitorri]

This reminds me of a report from a user a while back.
It seems that there are some errors on the BJT code. During calculation of the builtin potentials at high temperature (or frequency, i don't recall).
I will check my emails again and file the issue.
Manufactures measure the performance and fit the model to the available parameters. How they get it to be non-physical might have to do with with the fact that the model is simplified.

[scordilis]

clearly, I have never been able to fit a BFG403 or BFG425, and now BFU series since 2005 (as mentionned in the workbook at that time) ... by fitting I mean reproducing the Sparameter of a vendor using its own spice model (that s why I'm using the die + package description) .

I fully agree on the vendor way of treating the problem, but still the gummel poon shall do the job as it does for them.

[in3otd]

maybe the Qucs(ator) results could be compared with the (ng)spice results (Qucs-S could make this easier) just to be sure the Qucs(ator) model are fine.

[felix-salfelder]

On Thu, Sep 27, 2018 at 05:11:11AM -0700, in3otd wrote: maybe the Qucs(ator) results could be compared with the (ng)spice results (Qucs-S could make this easier) just to be sure the Qucs(ator) model are fine.

well (shameless plug), i obviously had gnucsator in mind. it works under Qucs and reads the same netlist.txt as qucsator. pick one out of 5 bjt implementations, or try a verilog-a model. there will always be situations where you need a different model implementation or a model from another vendor. that's why gnucap supports binaries compiled against other simulators. (i do not know about a device that reads .s2p. as usual, shouldn't be hard, but somebody will have to actually do it...)

[scordilis]

There is a simple conversion from s2p to spice netlist .... but it is out of scope. The idea is to have sufficient confidence in the model so that we can design blocks on some weird biasing. When I'm speaking about fitting, I do not aim to have exactly the same thing but at least to approach the S parameter ones. Today we are completely out of "spec".

I'm exploring the BJT modeling code ...

I'm also working on a comparison deck for ngspice or spiceopus ... to deal with that. qucs works fine for linear design but we need to solve that to promote NL modeling using qucs for RF and microwave. somebody have tried MOS or FET ?

[scordilis]

quoting from qucsator/src/components/devices/bjt.cpp

 /* Originally Vtf was expected to be PROP_POS_RANGE, but there are models
  * which use negative values. Instead of failing, warn the user.
  * \todo Provide a way to silece such warnings
  */
 nr_double_t Vtf = getPropertyDouble ("Vtf");
 if (Vtf < 0.0) {
   logprint (LOG_ERROR, "WARNING: Unphysical model parameter Vtf = %g in "
        "BJT `%s'\n", Vtf, getName ());
 }

my first impression is, that negative Vtf is not supported there. (i am not a bjt expert.)

can you please provide a slightly simpler example that shows the issue, ideally just netlist.txt and your (expected and actual) output?

thanks

For sure right now
Vtf = Vtf < 0 ? 1.0 / Vtf : 0;
..... have to dig into that.

but Nf and Nr are untouched it seems

[scordilis]

seems like SiGe NPN to have to be modeled using the VBIC model (see LTspice or ngspice documentation) ... therefore not the gummelpoon. So mainly it means that we can not use qucs any modern RF transistor !!! so it has to be added to the next release of qucs !!! And perhaps adding a level parameter in the NPN model.

even the biasing is wrong using the actual modeling. if you trace the Ic vs Vce for different Ib, the curve is definitely not correct.

I have succed in modeling the biasing using LTspice, but still have some issue with the S parameters vs the To specs.

For the warning, I think we shall indicate the limiting value also, not only saying unphysical ...
if (Vtf < 0.0) { logprint (LOG_ERROR, "WARNING: Unphysical model parameter Vtf = %g (< 0.0) in BJT %s'\n", Vtf, getName ()); }

http://ltwiki.org/index.php?title=Q_Bipolar_transistor
(Edit: corrected link)

nevertheless, I will try to check the NPN model on some old transistor, just to ensure this model ...

[felix-salfelder]

On Sat, Sep 29, 2018 at 10:54:03AM -0700, scordilis wrote: seems like SiGe NPN to have to be modeled using the VBIC model (see LTspice or ngspice documentation) ... therefore not the gummelpoon. So mainly it means that we can not use qucs any modern RF transistor !!! so it has to be added to the next release of qucs !!! And perhaps adding a level parameter in the NPN model.

in qucs, you can use your own devices through a loophole in the "User Libraries". this includes any modern RF transistor. (perhaps it's obvious, but seemingly not documented.) whether or not somebody is going to implement some other bjt it for qucsator, i don't know. but note how verilog-a(ms) support addresses the issue from a much better direction. perhaps the existing admsXML approach is worth a look. hth felix

[in3otd]

you can use your own devices through a loophole

now you got me curious: what's this loophole?
We could document it and have it become a feature. 😁

verilog-a(ms) support addresses the issue from a much better direction

I know nothing about Verilog-* but the [VBIC model]((http://www.designers-guide.org/VBIC/downloads.html) seems to be actually written in Verilog-A, so maybe it could be used without too much effort ??

[scordilis]

by the way the symbol of the BRF92A is wrong, it shall be NPN ;)

[victorpreuss]

Hi @scordilis,

I dug a bit into your project to see if I could help.

I saw the value of Tf in the spice model is different from the schematic.

also, in the package SOT343 schematic, the inductor Lc2 is missing and the value of Lb2 may be wrong. But more importantly, I think the pins that go out of the subcircuit and the pins that go to the BJT model are reversed. In the spice model the inductors Lb1, Lc1 and Le1 go to the output ports of the subcircuit and in your model I think they are going into the BJT instead of outside.

buuut as I was checking, the package influence is not that big up to 4 GHz (the spice model says to use it only up to 4 GHz).

i modified the schematic a bit (LNA_BFU730_prj.zip) (see the package schematic) but the results are still not a good match :(

the bias point that qucs returns is very close to the one I've obtained using ltspice, which is not close at all to the bias point presented at the s-parameters data of the transistor, therefore, I'm not sure if the s-parameters data and the transistor model provided by nxp are equivalent (at least not in the range I tested).

perhaps we could find another transistor to make some comparisons of this kind, since I'm not sure this spice model can be compared to the s-parameters data.

regards

[victorpreuss]

actually I found that the spice model was using M=3 (multiplicity) on the transistor model, so I've multiplied the transistor by 3 in the schematic and the results looked much better

[scordilis]

hi,
I'll have a look into it tonight ... for sure I have so many trials that there might still be some mistakes inside ... but my question is still valid regarding the level of modelisation that we can support in QUCS. What I know is that it fits pretty well on BFR92AW for instance ...

[scordilis]

by the way

I found that the spice model was using M=3 (multiplicity)

where did you saw that ?

[scordilis]

got it. it was in the original file, the provided spice was a modified version in order to be able to input it into qucs directly I guess ...

still Sopt is quite different for the rest of the process ...

for S11 S22 quite close indeed.

I do promote the fact that if we can reproduce some application note, it could be an example to place in the official example files.

Thx for your hints.

[victorpreuss]

i agree, i think for newer transistors more modern simulation models like VBIC or Mextram will have to be used and qucs will need to have support for them.

I do promote the fact that if we can reproduce some application note, it could be an example to place in the official example files.

i think it's a nice idea, i'll see if can work on something like that

still Sopt is quite different for the rest of the process ...

yes, not sure what happened there yet ....