Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Xyce conditional netlists

71 views
Skip to first unread message

Dietmar Warning

unread,
Aug 23, 2024, 12:25:38 PM8/23/24
to xyce-users
We try to transform existing simulation libraries from ngspice (formerly spectre) to Xyce.

We have following conditional constructs in subckt's:

.subckt sg13_lv_nmos d g s b
+ w=0.35u l=0.34u ng=1 m=1 as=0 ad=0 pd=0 ps=0 trise=0 z1=0.34e-6 z2=0.38e-6 wmin=0.15e-6 rfmode=0 pre_layout=1

.if (as <= 1e-50)
    .if (floor(floor(ng/2+0.501)*2+0.001) != ng)
        YPSPNQS103_VA M1 d g s b sg13g2_lv_nmos_psp w='w/ng' l=l mult='ng*m'
          + as='max(w/ng,wmin)*(z1+((ng-1)/2)*z2)/ng'
          + ad='max(w/ng,wmin)*(z1+((ng-1)/2)*z2)/ng'
          + ps='2*(max(w/ng,wmin)*((ng-1)/2+1)+z1+(ng-1)/2*z2)/ng'
          + pd='2*(max(w/ng,wmin)*((ng-1)/2+1)+z1+(ng-1)/2*z2)/ng'
          + dta=trise
          + ngcon=2
    .else
        YPSPNQS103_VA M1 d g s b sg13g2_lv_nmos_psp w='w/ng' l=l mult='ng*m'
          + as='max(w/ng,wmin)*(2*z1+max(0,(ng-2)/2)*z2)/ng'
          + ad='max(w/ng,wmin)*z2/2'
          + ps='2*(max(w/ng,wmin)*(2+max(ng-2,0)/2)+2*z1+max(ng-2,0)/2*z2)/ng'
          + pd='max(w/ng,wmin)+z2'
          + dta=trise
          + ngcon=2
    .endif
.else
    YPSPNQS103_VA M1 d g s b sg13g2_lv_nmos_psp w='w/ng' l=l as='as/ng' ad='ad/ng' pd='pd/ng' ps='ps/ng' mult='ng*m'
      + dta=trise
      + ngcon=2
.endif
.ends

How we can do this if/else/endif constructs in Xyce?

xyce-users

unread,
Aug 23, 2024, 12:32:35 PM8/23/24
to xyce-users

Hello Dietmar,

Unfortunately, .IF conditionals are not yet supported in the Xyce parser.  It has been on my "to do" list for a while, but I've had to focus on some other priorities.  It is probably the most prominent parser compatibility gap that we have.  I do hope to resume work on it soon.    The current structure of the parser makes it difficult, and it will probably require a substantial refactor.

thanks,
Eric

Kevin Cameron

unread,
Aug 23, 2024, 12:46:08 PM8/23/24
to xyce-users
For anyone interested, I have a Verilog-AMS parser (it does if/then/else) -


- my intent was to plug in things like Xyce and Verilator, but Xyce was somewhat late in getting GPL.

If/then/else constructs can be translated to multiplexors.

My current focus is "federated simulation" where most of the complexity is moved into the federation layer, and I don't have to rely on folks owning the simulators to do stuff - we invented Verilog-AMS almost 30 years ago as a replacement for SPICE, but people insist on reinventing the wheel. The federation layer will be C++ with Python scripting. In this case I'd be using the federation layer to translate V-AMS to whatever Xyce understands.

Kev.



--
You received this message because you are subscribed to the Google Groups "xyce-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/d8d203c9-a8bb-4c4b-be39-5ca13781bde7n%40googlegroups.com.

xyce-users

unread,
Aug 23, 2024, 1:10:37 PM8/23/24
to xyce-users

To clarify the hard part of implementing this in Xyce isn't the parsing itself. I've also implemented conditions in other parsers, including Xyce's expression library.  That part isn't difficult.

The hard part has to do with the current parser structure, and the related order in which Xyce's parser resolves information.   It is currently a two-pass parser, and the .IF statement conditionals would need to be fully resolved in the first pass for it to work properly.  The conditionals generally depend on .params, and the Xyce parser doesn't fully resolve all parameters until the second pass.     This was done for efficiency, as the first pass is serial and the second pass is parallel (mostly). 

This is fixable, but it requires code re-arrangement that needs to be done carefully.  It would be easy to make a mistake and break it.  But also it will result in less of the parser being parallel, and thus potentially slower.  My preference is to find a way to do it that doesn't hurt performance too much.

Eric

xyce-users

unread,
Aug 23, 2024, 1:11:49 PM8/23/24
to xyce-users
PS. I meant to say "conditionals", not "conditions" in the last message.

Eric

Kevin Cameron

unread,
Aug 24, 2024, 5:50:42 AM8/24/24
to xyce-users
It's rare for a parser to take up significant time in an analog simulation run, no matter how badly written it is.

At this point I'm against net-listing in general, it's one of the things that gets in the way of fast turnaround on design changes, for analog stuff that's coming out of schematics you really just want APIs between the schematics editor and simulator so they can be working simultaneously. I.e. you would be better off with an OpenAccess bridge than using any kind of SPICE format net-list.

Kev.

xyce-users

unread,
Aug 24, 2024, 12:23:13 PM8/24/24
to xyce-users

A lot of our users are using modern PDKs and the SPICE files in them can be complex.   For example I recently worked with a 12nm PDK.  The AST resulting from parameter resolutions was over 50,000 nodes deep.    An earlier version of our parser had a bottleneck that prevented this from parsing efficiently (or at all, actually).   That got fixed.   Other modern PDKs have similar issues in my experience and they get worse at smaller process nodes.

I'm not worried about the parse times for 99% of analog circuits which are of modest size.  But we have users who need to run very large circuit simulations, on the order of 10M-100M transistors.    At that scale, every little performance improvement matters.   Earlier in the project we didn't care that much about optimizing the parser, because we figured its cost would be amortized over the course of a simulation, and the most important costs were in model evaluations and numerical solvers.   But, we learned the hard way that parser performance also matters, at least for large scale.

I understand the argument that "netlists are bad".  But we don't have the luxury of ignoring them given our user base.

We are familiar with OpenAccess, but haven't had the bandwidth to pursue it yet.

Eric
Reply all
Reply to author
Forward
0 new messages