Xyce and hspice model files

[Keith Sabine]

I'm finding that if I include a top level hspice model file (tsmc 40nm) in Xyce e.g

.lib /Users/fred/Desktop/hspice/crn40lp_1d8_v2d0_2_shrink0d9_embedded_usage.l TOP_TT

Then Xyce fails to find a file included from this file e.g.

.lib TOP_TT

.lib './crn40lp_1d8_v2d0_2_shrink0d9_embedded_usage.l' TTMacro_MOS_MOSCAP

.lib './crn40lp_1d8_v2d0_2_shrink0d9_embedded_usage.l' TT_RES_BIP_DIO_DISRES

.lib './crn40lp_1d8_v2d0_2_shrink0d9_embedded_usage.l' TT_RTMOM

.lib './crn40lp_1d8_v2d0_2_shrink0d9_embedded_usage.l' TT_IND_JVAR

.endl TOP_TT

It seems Xyce doesn't understand that '.' in this case is the current directory of the .lib path.

Is there a workaround for this?

[xyce-users]

Keith,

This is a known issue with the various Spicen, and the Xyce Team does intend to work on this issue.  It's unclear if that will happen in March, or at a later date.

There are two issues.  The first is the "general ickiness" of Unix-like OS vs. Windows.  That is all solvable, of course.  Which OS are you using?

The second (more important) issue is that various non-Xyce Spicen actually appear to handle this relative path issue in different ways.  My research back around Thanksgiving showed that the following was true.  So, the Xyce Team also needs some internal discussion about what "improved compatibility" actually means for this feature request.  (For Sandia readers, this topic is SON Bug 1325.)

Define:

P1 = path relative to the directory of the file with the .INC ( or .LIB) line

P2 = path relative to the directory of the top-level netlist.

Then this appears to be true, where "fallback" means that P2 is used if P1 does not exist. Absolute paths are also supported by all four simulators.

Code         | P1 Supported                    |  P2 Supported

HSPICE    |  Yes, for .INC and .LIB      |  Yes, as a fallback for .LIB and .INC

ngspice    |  Yes, only for .INC             |  Yes for .LIB, and as a fallback for .INC

Xyce 7.2   |  No                                      |  Yes, for .LIB and .INC

PSpice     |   No                                      |  Yes, for .LIB and .INC

Other than moving your library files, a Skywater PDK user mentioned using symbolic links to work-around this compatibility issue.  See https://github.com/google/skywater-pdk/issues/186#issue-725121773, and search on "symbolic link".  I agree, in advance, that both approaches are "not-optimal".

Thanks for bringing this issue to our attention.  We do appreciate your comments and feedback.

--The Xyce Team 

[Keith Sabine]

Unfortunately Xyce just doesn't seem to like Hspice format models regardless of where I put them.

e.g. I have in ~/Desktop (this is a Mac running Big Sur):

test.cir

c013hv32v.l

Then running 'xyce test.cir' gives:

***** Reading and parsing netlist...

Netlist error in file test.cir at or near line 22

 Model is required for device M6 and no valid model card found.

Line 22 is:

M6 n3 n3 vss vss nch w=1u l=130n m=2

and the library declaration is:

.lib './c013hv32v.l' TT

This is a standard tsmc 130nm model file with binning i.e models nch.1, nch.2 etc. and within the model the TT case is:

.LIB TT

.param

..... list of params....        

.lib 'c013hv32v.l' MOS

.ENDL TT

I guess no-one uses Xyce for IC design?

regards

Keith

[xyce-users]

We have run Xyce on TSMC PDKs in the past, so that isn't the problem. 

From your comment, it looks like you are having a problem with model binning.  If so, then you have to add this option to the Xyce input file:

.options parser model_binning=true

In Xyce 7.2, model binning is not turned on by default.  It was a relatively new capability so I wanted to make sure that I didn't break anything.  In the next Xyce release (7.3) it will be on by default.  Also, it is  on by default in our internal development branch at Sandia, so the next time we merge to the public git repo, the new default behavior will be there.

In XDM translated netlists that option for model binning is automatically added.  Are you using XDM or translating by hand?

Also, regarding the path issue, above.  If you run XDM on a netlist that calls a PDK, it can recursively translate all the PDK files and place the translated files in the local directory.  If you do it that way, then the path issue is moot.  Of course, it isn't desirable to have many copies of translated files floating around, which is why we're working to fix the relative path issue.  I'm hopeful that will be done for 7.3.

thanks,

The Xyce Team

[xyce-users]

FYI, if you aren't familiar with the XDM tool, it stands for "Xyce Data Model".  It is a netlist translator and is designed to convert input files from various circuit simulators to Xyce format.    The supported formats are PSpice, Hspice and Spectre.   The Spectre grammar is very new, so support for that language is probably not as robust yet.   The Pspice and Hspice grammars are fairly mature at this point.

XDM can be downloaded from our Sandia website.   (It isn't on github yet) You can find the user guide here:

https://xyce.sandia.gov/downloads/_assets/documents/XDM_User_Guide.pdf

thanks,

The Xyce Team

[Keith S.]

Thanks, the model_binning option solves the problem if I run from the cmd line e.g.

/usr/local/Xyce-Release-7.1.0-OPENSOURCE/bin/Xyce /Users/keith/Desktop/test.cir

However... if I run Xyce from code (using a Qt QProcess), Xyce runs but gives an error:

***** Executing netlist /Users/keith/Desktop/test.cir

***** Reading and parsing netlist...

Netlist error: Could not find include file c013hv32v.l

There is obviously something strange going on here, as the models are in the same directory as the netlist. And if I call spice3f5 instead of Xyce from code, with the same netlist, it works just fine,

regards

Keith

[xyce-users]

Hi Keith,

I am guessing that the Qt program you are using to run Xyce jobs is (effectively) launching them from a different directory than the one where the netlist and libraries are, and this would matter.

For any relative paths, there a various options we could have chosen for the reference directory.  As it turns out, the choice we made was not consistent with what other simulators do and (as mentioned above) we're working to correct that.  

Currently, Xyce applies relative paths for include files relative to the execution directory, not the netlist directory.  I am guessing in your command line example, these two directories are the same, but in the Qt example they are not.

So, keeping with command line examples, this should work:

cd /Xyce /Users/keith/Desktop

/path/to/Xyce  test.cir

But this will not:

cd /some/random/directory  (not /Users/keith/Desktop)

/path/to/Xyce    /Users/keith/Desktop/test.cir

and you would get that error.

So, either the relative paths need to be changed to absolute full paths (which completely avoids the issue), or you need to run it from the same directory as the files. 

As was mentioned earlier in the thread, we're working to fix this issue to handle relative paths in a manner that is more consistent with other simulators.  Hopefully that will be fixed for the 7.3 release this spring.

thanks,

The Xyce Team.

[Keith S.]

Aargh.

I had unintentionally set the process working directory to the simulator path, rather than the netlist directory. Once corrected this behaves as expected. Of course handling relative paths to the current include/lib file is the way to go so I look forward to 7.3.

Keith

[xyce-users]

Keith,

Xyce should now handle paths for files on .INC and .LIB lines like HSPICE does.  That change was pushed to https://github.com/Xyce/Xyce last weekend, if you build from source.  If you're waiting for the official Xyce 7.3 release, before trying that new feature, then that should happen "soon" but likely not in April.   The fix should be good on Linux, OS and Windows.

--The Xyce Team