<!channel>: Xyce just updated its github repo yesterday with support for

M=

on subcircuits and for use of parameters referencing other parameters on the same line. These were two major issues with sky130 compatibility. I am recompiling now and will report on testing of both issues.

@User Great! I’ll be interested to hear how it goes. I added those features just last week. So you’ll be one of the first people to try them out, outside of the regression tests I created.

@User: The handling of parameters and subcircuit M value work as advertised. I have one small nit to pick, though, as I have a definition

.subckt  sky130_fd_pr__nfet_01v8_lvt  d g s b  mult=1
.param  l = 1 w = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w}
+ nrs = {0.14/w} sa = 0 sb = 0 sd = 0 nf = 1
...

and made a testbench with

X1 3 2 0 0 sky130_fd_pr__nfet_01v8_lvt W=3.0 L=0.15 M=1
+ ad = ' int((nf + 1)/2) * W/nf * 0.29 '
+ as = ' int((nf + 2)/2) * W/nf * 0.29 '
+ pd = ' 2 * int((nf + 1)/2) * (W/nf + 0.29) '
+ ps = ' 2 * int((nf + 2)/2) * (W/nf + 0.29) '
...

This fails to parse in Xyce until I add

NF=1

to the

X1

instance above. My expectation would be that the instance implicitly defines the default parameter and value

nf = 1

, so that if I use

nf

in another parameter, but I have not otherwise (re)defined

nf

, then it should assume the default value of

1

instead of throwing an error. This is not necessarily an error, and xschem, for one, always writes out the

NF

parameter value in the instance call, it's just that it seems to me that known subcircuit parameters should be recognized within an equation and the default values used if not present in the instance call (I do recognize that there are valid reasons to argue against this).

@User glad to hear that M= works as it should!

Well, the

M

value parsed cleanly and didn't throw the warning message that it used to. I do need to check that the output is properly scaling with the value of

M

. I need to do a bit of translation between ngspice and Xyce syntax first.

The reason Xyce previously didn’t handle parameters referring to each other on the same “X” line is that they were considered to be basically the same as device instance parameters. And device instance params don’t refer to each other. Anyway, they were all handled by the same function. “X” parameters are now handled by a new function, but I didn’t change the scoping for it.

I do not quite follow your first response. If the child-scoped expression sees everything in the parent, then shouldn't it see the parameter name

NF

and the default value that exists in the parent?

In your code fragment, you have nf=1 inside the subckt. That’s the child scope. The X1 line doesn’t (that I can see) have nf defined. That’s the parent scope. So the expressions on the X1 line that depend on nf can’t be resoved, as they can’t see into the child scope.

Yes, that makes sense. I was just inverting the concept of "parent" and "child" in my mind. An instance and its subcircuit don't really have a "parent":"child" relationship per se; I think of the subcircuit as more of a template for the instance. At any rate, it is just a "small nit", as I said, and I don't think it will have any impact if you leave it the way it is.

thanks; the terminology parent/child isn’t perfect but it was the best I could think of at the moment. 🙂

@User

Xyce

might be in a state now that you could consider clean integration into

xschem

#xschem

@User yes, time to test more Xyce. @User Great improvements!.

@User and @User, just to alert you, the new M= had a bug in it that I found yesterday. The bugfix has been push to our public git repo, so you may want to do an update and rebuild. If curious, the specific bugfix is here in this commit: https://github.com/Xyce/Xyce/commit/a3c4185ec1b4b5089164ec7e9b50cfffec4a1bbc

@User: Okay, thanks, I'll update.

Thanks @User i will shortly rebuild Xyce (i did the full thing one day before the m= commit 🙂 )