Get Xyce and the PDK playing nice together

[mithro]

Expected Behavior

• You are able to use Xyce for doing analog spice simulations inside the skywater-pdk

Actual Behavior

• It doesn't work

Comments

I'm creating this bug to track the various issues people have discovered when trying to use Xyce with the skywater-pdk.

[pepijndevos]

From my understanding the blocking issue is that Xyce does not support the scale option. I've seen some talk about removing it, but it appears a tough nut to crack. The scale option only applies to physical sizes, but not to other physical units like capacitance. This, combined with the deep hierarchy makes it very tricky to rewrite all the equations without the scale option. People who know what they are talking about said automated solutions are tricky because of the way it applies in only some contexts, so simply replacing W with W*1e-6 will break calculations in non-scaled contexts.

The other option would be to add support for the scale option to Xyce, but it is thought that they probably have little interest in this admittedly stupid option. Maybe @peshola could comment on this?

Worth noting that Magic also uses some hack where everything is essentially unscaled by 1e6 so that the final result comes out right. So in this sense removing the scale option would improve tool support across the board. It's just a tricky thing to do.

Maybe ngspice itself could be used as a library to do AST transformations? Because it understands the scale option, I imagine it has a bigger chance of success than regex based approaches.

[adrianfreed]

It might be interesting to provisionally add the ngspice scale option to Xyce. This would make it possible to evaluate Xyce compatibility in other areas and in particular evaluate the benefits of Xyce's parallel solver. Both the recent FOSSI talks (OSU cells, OpenRAM) emphasized characterization and simulation bottlenecks.

[adrianfreed]

Here is an excerpt of some of the errors I see after trying to load the library with a .lib TT card. There are issues with relative include file names. I think Xyce might require absolute path names. Their documentation talks of paths relative to the directory of the executable.

Netlist error in file corners/tt/nonfet.spice at or near line 24 Equal sign (=) required between parameter and value in .PARAM statement

Netlist error: Could not find include file

Netlist error in file parasitics/sky130_fd_pr__model__parasitic__diode_ps2nw.model.spice at or near line 16 Parameter $ not formatted correctly in .model SKY130_FD_PR__MODEL__PARASITIC__DIODE_PS2NW

sky130_fd_pr__nfet_01v8_lvt__tt.pm3.spice

Netlist warning in file all.spice at or near line 2 Unrecognized dot line will be ignored

.ENDL encountered without library name, currently inside .LIB TT

[adrianfreed]

Xyce doesn't support $ end of line comments which are peppered in many of the .param cards of sky130.

This probably causes the "$ not formatted correctly error" and "= sign required" errors above.

[adrianfreed]

The "unrecognized dot line will be ignored error" is the infamous scale line: .option scale=1.0u

[adrianfreed]

The ".ENDL encountered without library name, currently inside .LIB TT" error can be fixed by making sure all the .endl cards are followed by the name of the library they terminate. This fix is compatible with ngspice

[adrianfreed]

It looks like the .option problem is the significant show stopper in terms of the sky130 spice device library.

For the spice decks in the tests folders the problem is that they use the ngspice interactive mode language (the cards without "." in front of them) . This isn't available in xyce.

[peshola]

This statement above, "Xyce doesn't support $ end of line comments", is correct. Xyce uses ; (semicolon) as its in-line comment character.

[Karlsefni2012]

We have the "scale" option as a feature request in our internal issue tracker. That is something we can expedite.

[Karlsefni2012]

Also, note that we (Xyce) have a file translation tool (XDM) that can handle some file compatibility issues. In Xyce we use ".options <package_name>" instead of .option.

[Karlsefni2012]

I am pleased to announce that I managed to add "option scale" to Xyce as of today. It is still running thru regression testing, but hopefully (knock on wood) will be in the public git repo for Xyce in the near future, possibly next week.

As Xyce uses a slightly different specification for options, the netlist command for "scale" is in this format:

.options parser scale=1.0e-6

Converting it to that format from ".option scale=1.0e-6" is the kind of thing our XDM tool can do, at least in theory.

[mkghub]

I have did some experiments on the spice files without 'option scale'. And have done some test simulations. Manual editing is required for some files, as is stated above. So some regression tests are needed to have a confidence.

There are a few other compatibility issues, after solving the option scale problem. Maybe developers of Xyce can give hints for best solutions?

• 1. Temperature variable 'temp' variable cannot be used in the equations. A temporal solution is modifying 'temp' to 'temper' in the equations and defining 'temper' as a parameter on the input file. This method is OK for doing simulations on a fixed temperature but not OK for temperature sweep.
• 2. voltage dependent resistor models Node voltages cannot be used in equations. In XDM manual, it is said that the solution for this problem is using behavioral current source models. For now I don't know how to incorporate both temperature dependence and voltage dependence. If we can neglect the voltage dependence of poly resistors it is OK.
• 3. Diode model don't support level 3 model In diode model files, level = 3.0 is defined. For Xyce there's only level 1 and 2.
• 4. Environment variable in include path statement For hspice and specter, an environment variable can be used in include path statements. For Xyce I don't know how to do it. For example .inclue "$sky130_fd_pr/models....." works for hspice and specter but Xyce refuses it. A temporary solution which I am using for now is defining symbolic link under the simulation directory such as 'sky130_fd_pr' and using it in the spice files. .include "sky130_fd_pr/models..."
• 5. 'vt' variable This is a trivial problem. In one file, 'vt' is used as a parameter variable. This needs to be modified to something like 'vt0'.
• 6. In line Comments Changing '$' to ';' is OK for ngspice, Xyce, and hspice, etc.
• 7. Model Binning This is not an issue. The following statement is needed in the input file for using binning models. .options parser model_binning=true

I am doing the tests and modifications for personal interests with the files on the repository https://github.com/mkghub/skywater130_fd_pr_models

[Karlsefni2012]

Regarding the use of temperature (TEMP or TEMPER) in equations, that is being worked on.

In the meantime, I think it is good to clarify one aspect of equations in Xyce. They are used in a lot of contexts, of course. In some contexts, TEMP is allowed, and in some others it is not. Here are two examples.

In Xyce .param and .global_param are treated very differently. .param are basically static and cannot contain anything (user variables, voltage nodes, special variables, etc) that might change during a simulation. .global_param, on the other hand, are allowed to change during a simulation. So, you can think of .param as being kind of like a parser-level string substitution, and a .global_param as being a true variable. A .param is set up during parsing and then not tracked after that.

So, this is legal:

.global_param gp1={2*TEMP}

And this is not:

.param p1={2*TEMP}

Also this is not legal, because temp is a reserved simulator variable:

.param temp=23.0

Behavioral sources (which use equations) can use temperature. For example, in our test suite, see this input file: Xyce_Regression/Netlists/Certification_Tests/BUG_606_SON/bug606son.cir.

Netlist to demonstrate Vt bug
**************************************************************
* This netlist tests SON Bug 606, 654 and 1033.  SON Bug 606
* was about making VT work within expressions.  SON Bugs
* 654 and 1033 are then about making TEMP and VT work
* correctly as "dependent parameters" for all Xyce devices.
**************************************************************

B2 3 0 V={TEMP+273.15}
R3 3 0 1

B3 4 0 V={Vt}
R4 4 0 1
.OP

.step TEMP 27 30 1
.PRINT DC V(3) {TEMP+273.15} {(TEMP+273.15)*(1.3806226e-23/1.6021918e-19)} V(4) {Vt}
.END

This ties into the second issue you raise, about voltage dependent resistor models. As you note the XDM guide suggests replacing something like this:

R1   1  2   ’P1*v(in,out)’

with this:

B1 1 2 I={(V(2)-V(1)/(P1*v(in,out))}’

If you needed to incorporate TEMP into the equation for B1, that should work. It just can't come thru a .param

I should note that we've been doing a LOT of work on expressions in Xyce. We are about to release 7.2, in which the Xyce expression library has been completely replaced with a new one. The new one addresses many, many long standing expression-related issues, including the use of complex numbers.

The new expression in 7.2 partially addresses the difference between .param and .global_param. The new library doesn't treat .param as constants. So, going forward we should ultimately be able to make .param behave the same as .global_param. That isn't quite done yet, as while the new expression library treats .param as non-constant, the rest of the Xyce source hasn't yet been updated to reflect this change. But I expect that this will be fully propagated thru the rest of Xyce over the coming months.

[peshola]

To add to the previous comment, if you look in the Xyce Regression test suite then the tests in Netlists/Certification_Tests/BUG_1203_SON show various ways that the TEMP (or TEMPER in the upcoming Xyce 7.2 release) special variable can used in a .GLOBAL_PARAM in an expression for a device instance parameter. If those examples don't cover your usages then please let us know, as the Xyce Team has been fixing the use of special variables over the past few release cycles.

Issue 4 ("Environment variable in include path statement") is something that we are aware of. I hope to investigate that feature request in the near future, to at least scope out a path for adding it (or something like it) to Xyce.

[mkghub]

Thank you for your response. I have read the above Regression test suite and did test again with Xyce 7.2. Now, I am in the same state as before. Maybe I am missing some points.

For example, the device subckt definition has the parameter .param vc1_end = {vc1_raw_end*(1+tc1_voltco*(temp-30))}

Since, 'temp' cannot be used, one can use 'temper' instead, as shown below .param vc1_end = {vc1_raw_end*(1+tc1_voltco*(temper-30))}

In the input file, I have tried the following,

.global_param temper = {temp}

It gives the same error as using 'temp' directly.

How to make the 'temper' variable follow 'temp' exactly, even when we are doing temperature sweep?

[peshola]

Does this syntax work in your netlist?

.global_param vc1_end = {vc1_raw_end*(1+tc1_voltco*(temp-30))}

As Eric alluded to above, for historical reasons that are being slowly corrected, .PARAM and .GLOBAL_PARAM are not the same in Xyce. Also, .PARAM in Xyce still acts differently than .PARAM in HSPICE. This is also being slowly fixed.

On another note, we are working towards making TEMPER and TEMP into synonyms in Xyce. However, that work is on the most recent version of our master branch available at github, and is not in Xyce 7.2.

[mkghub]

If I use .global_param inside of subcircuit statements, I get the following error. "Attempt to assign global_param inside of subcircuit"

[peshola]

And I assume that it's inconvenient to move the .global_param statement outside of the .subckt statement because some element of the expression vc1_end = {vc1_raw_end*(1+tc1_voltco*(temp-30))} may be different in different instantiations of the subcircuit in your netlist?

[Karlsefni2012]

Hello everyone, I wanted to give an update on this issue.

Recently (past few weeks) a number of changes have been pushed to the official public Xyce git repository, which should impact the use of Xyce on the Skywater PDK. There is still more to do, but several of the issues mentioned in this thread have been fixed. The various improvements include:

1. Model binning is now on by default, and doesn't need to be turned on from the netlist.

2. .param is much more flexible now, and is allowed to be set to "special" variables like TEMP. Previously only .global_params were allowed to do this, for historical reasons. Most distinctions between .param and .global_param are now gone. (long story there, not really worth getting into here)

3. .LIB and .INC now support relative paths.

[peshola]

To clarify the relative path fix, various Spicen actually appear to handle this relative path issue in different ways. My research back around Thanksgiving showed that the following was true. 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. (I should be verifying what Spectre does, shortly.)

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

Xyce should now handle paths for .INC and .LIB files like HSPICE does. The fix should work on Linux, OSX and Windows, and was pushed to github last weekend. If folks still have concerns about this feature request then please post a comment here. If we need to make Xyce support both the HSPICE and ngspice behaviors then that should be doable, but it might require a command-line switch.

[GlenHertz]

FYI. If my memory serves me right HSPICE will search for:

1. Relative to dir of file
2. Relative to dir of top netlist
3. Relative to dir of where it was launched from

It will also look for .gz extensions at each step if they exist (so .inc foo.sp will look for foo.sp and then foo.sp.gz).

[Karlsefni2012]

@GlenHertz thanks! that is helpful. We'll double-check those use cases for HSPICE. What is currently in the development branch may not do all of that yet.

[peshola]

@GlenHertz You were correct.

Both "relative to dir of top netlist" and "relative to dir of where it was launched from" work in HSPICE. The relative priority, between options (1), (2) and (3), is also correct in your comment. I did not test the .gz extension feature.

Xyce 7.2, and earlier, makes an implicit assumption, when handling .LIB and .INC file paths, that the "dir of the top netlist" is the same as the "dir of where Xyce was launched from". So, your options (2) and (3) don't always work correctly in Xyce 7.2, if that assumption is false.

Both (2) and (3) in your comment should now work with what is currently in the development branch of Xyce available on github. This should be true even if the "launch directory" and the "dir of the top netlist" are different. However, I'm still working on test cases to verify that is true in general. (For the internal Sandia readers, I may also change the new function handleIncludeFilePath() in the file N_IO_ParsingHelpers.C to more explicitly handle (3).)

[GlenHertz]

Oh, good to hear my memory is still OK. A quick tip to figure out what a program does is to run in on Linux with:

strace -f -e open,stat ngspice path/to/netlist.sp

And just use a missing file for the .lib or .include and it will print out everywhere it looks so you don't have to test it a bunch for different scenarios and guess. If you want to see more output then remove the "-e open,stat" part.

[peshola]

@GlenHertz . Thanks for the pointer to strace. A useful tool.

My comment from a few days ago was wrong. The version of Xyce currently available at github only looks in (1) "Relative to dir of file" and (3) "Relative to dir of where Xyce was launched from". I have a version of Xyce, on a local branch, that also looks in (2) "Relative to dir of top netlist". So, that feature might should also be available, on github, in a few weeks after some more refinement and testing.

Adding a command-line switch to mimic any differences, in the file search path behavior, between HSPICE and ngspice is doable. But I'm not currently planning to do that unless there's a clear need for it.

[peshola]

Based on the output from strace, it appears that ngspice's search order (for ngspice-33) is:

1. "Relative to dir of where ngspice was launched from"
2. /install/path/share/ngspice/scripts
3. Relative to dir of include file

So, that is actually quite different from HSPICE.

[umarcor]

A few days ago, I added Xyce to hdl.github.io/containers, so there is now a container that users can try for testing/using Xyce. It's available as hdlc/xyce or ghcr.io/hdl/debian-buster/xyce.

# docker run --rm -it hdlc/xyce Xyce -v
Xyce Release 6.12-opensource

As you can see, it is currently based on the versions I used in december 2019, when testing co-simulation betwen GHDL and Xyce (https://ghdl.github.io/ghdl-cosim/vhpidirect/examples/vffi_user.html#xyce): https://github.com/hdl/containers/blob/main/debian-buster/xyce.dockerfile#L51-L54. However, since all other tools in hdl/containers are built from main/master/head branches, I'd like to update Xyce too.

@peshola, since Xyce is very dependent on Trilinos, what procedure do you suggest? Trilinos 12.12.1 is still recommended in https://xyce.sandia.gov/documentation/BuildingGuide.html#instTrilinos. Should I stick to that and pick master of Xyce only?

[peshola]

@umarcor I'm not the best Xyce person to discuss building Xyce within docker. However, I will ask someone on the team to engage with you, We will be releasing Xyce 7.3 in the next month, or so. So, it may be a good time to think about this topic.

[umarcor]

@peshola, in this case, building within docker is not different from building it on a Debian host: https://github.com/hdl/containers/blob/main/debian-buster/xyce.dockerfile#L27-L118. I might convert that to a regular shell script, should someone on the team want to have a look at it. The issue after bumping to 7.2 is that some dependency/tool seems to be missing. Note /bin/bash: no: command not found in the following log (https://github.com/hdl/containers/runs/2320141138):

2021-04-12T03:24:00.3673607Z #9 1257.0 Making install in ExpressionSrc
2021-04-12T03:24:00.3704422Z #9 1257.0 make[4]: Entering directory '/tmp/build/xyce-build/src/UtilityPKG/ExpressionSrc'
2021-04-12T03:24:00.3706362Z #9 1257.0 no -oExpressionParser.cxx ../../../../Xyce/src/UtilityPKG/ExpressionSrc/ExpressionParser.yxx
2021-04-12T03:24:00.3712665Z #9 1257.0 no  -i -+ --full  --prefix=exp  -oExpressionLexer.cxx ../../../../Xyce/src/UtilityPKG/ExpressionSrc/ExpressionLexer.l
2021-04-12T03:24:00.3715787Z #9 1257.0 /bin/bash: no: command not found
2021-04-12T03:24:00.3716895Z #9 1257.0 make[4]: *** [Makefile:759: ExpressionParser.cxx] Error 127
2021-04-12T03:24:00.3718075Z #9 1257.0 make[4]: *** Waiting for unfinished jobs....
2021-04-12T03:24:00.3719869Z #9 1257.0 /bin/bash: no: command not found
2021-04-12T03:24:00.3721477Z #9 1257.0 make[4]: Leaving directory '/tmp/build/xyce-build/src/UtilityPKG/ExpressionSrc'
2021-04-12T03:24:00.3722823Z #9 1257.0 make[4]: *** [Makefile:762: ExpressionLexer.cxx] Error 127
2021-04-12T03:24:00.3724353Z #9 1257.0 make[3]: Leaving directory '/tmp/build/xyce-build/src/UtilityPKG'
2021-04-12T03:24:00.3726019Z #9 1257.0 make[3]: *** [Makefile:781: install-recursive] Error 1
2021-04-12T03:24:00.3727013Z #9 1257.0 make[2]: *** [Makefile:938: install] Error 2
2021-04-12T03:24:00.3728393Z #9 1257.0 make[2]: Leaving directory '/tmp/build/xyce-build/src/UtilityPKG'
2021-04-12T03:24:00.3729948Z #9 1257.0 make[1]: *** [Makefile:886: install-recursive] Error 1
2021-04-12T03:24:00.3731292Z #9 1257.0 make[1]: Leaving directory '/tmp/build/xyce-build/src'

Anyway, no rush at all. I just provided this info so you can forward it to whoever. Ping me at your own will.

[TBird2001]

@umarcor, your inquiry comes at an interesting, perhaps opportune, point. We are in the process of moving from autotools to CMake for our primary build system. In the upcoming 7.3 release of Xyce, CMake build instructions will be provided for the first time. We've tried to make it easier than the autotools approach, so it may be simpler to create the Debian container using CMake. Also, CMake is the future for Xyce, so you will have to move to it at some point. Nevertheless, since it is the first time anyone other than us will be using the CMake system, there is the possibility of bugs (hopefully minor ones).

If you decide to try the CMake, I'd be happy to help you troubleshoot as needed (as it would be good to get some external feedback). The instructions will be in a new INSTALL.md file, which should get pushed to GitHub around next Monday (the 19th).

As to your Trilinos question, we will be using 12.12.1 at least through the 7.3 release. Being better compatible with Trilinos is actually one of the drivers for the move to CMake, as they will be dropping their autotools support soon. Also, an upcoming Trilinos release will have a solver that we hope to leverage. As such, we will eventually start tracking Trilinos more closely, at least in terms of their releases. For the time being, though, you should be able to use the same build of Trilinos 12.12.1 for the next six months, at least.

Regarding the install issue in your second comment, I have no idea what is going on. I've asked for some help from others in our group. Hopefully we will have something soon.