Frequently Asked Questions

Answers to Frequently Asked Questions

Does Xyce have a Schematic Capture GUI?

Xyce is just the simulator. However, Xyce has been integrated into some freely-available tools. We are aware of the following toolsets:

  • Xschem is a schematic editor that can call Xyce for simulation. The manual has instructions for integrating various waveform viewers The combination can be used with the SkyWater open-source PDK.
  • Revolution EDA is a schematic and layout editor that can call Xyce. The documentation has installation instructions and a tutorial section.
  • Typhoon-HIL has a freely available Schematic Editor that can use Xyce for simulation. See their Xyce Integration page for more details.
  • Xyce can be integrated into the gEDA toolkit. A report on that procedure is on the Documentation page.
  • The Qucs-S project allows the schematic capture component of Qucs to access several different simulators, including Xyce.

Is there a Xyce support or discussion forum I can join?

Yes, there is a Google Groups forum that you can join to discuss Xyce. The Xyce team is subscribed to this forum and can provide some help with issues posted there. To view and join the group through a web browser, go to https://groups.google.com/forum/#!forum/xyce-users, log in to a Google account, and click the “Join” link. To join via email without a Google account, send a subscription request to xyce-users+subscribe@googlegroups.com. Please include the approximate date when you requested a Xyce download account and the email address you used for that purpose in your subscription request so we can confirm that you are a Xyce user. If you obtained Xyce through another mechanism we may ask for additional information before confirming your subscription.

Can I call you on the telephone for support?

The Xyce team does not have the resources to provide telephone support for Xyce, and we can provide support only via the Google Group or the email address you can find on our “Contact Us” page. No phone number that you might find in the various links at the bottom of the Xyce web site can be used to contact us—these are all just part of the Sandia web server’s boilerplate, and contain only general information numbers for Sandia National Laboratories.

Why is the code called “Xyce?”

Since Xyce is not a derivative of the original Berkeley SPICE, we did not want to have a derivative name (like S-SPICE, for Sandia-SPICE). However, to maintain the tie to the archetypal circuit simulator, we decided the name should rhyme with “SPICE.” One of the developers had read an article that said companies whose name began with ‘X’ had higher success rates (this was the year 2000, after all), and he suggested the name “Xyce.” Eventually, the name stuck. Note that the proper pronunciation is “zīs,” and that “Xyce” is not an acronym, so it should not be written “XYCE.”

Why do you require a registration page for your download site?

The registration page was a Sandia requirement when we were given the original approval to release Xyce to the public.

Since that time, we have been given permission to maintain a limited GitHub repository for Xyce and Xyce_Regression. They can be found at https://github.com/Xyce. These repositories contain truncated histories of the code and test suite starting on 9 May 2019. They are updated from our internal repository on a roughly weekly cycle. Code on the master branch is generally stable and passes our test suite at the time it is pushed, but has not been put through our full release QA process. The Xyce team recommends that only code tagged as a numbered release be used for production work.

Binaries of Xyce release code and PDF copies of the documentation are still only available through the xyce.sandia.gov download site.

Some GitHub users have created GitHub repositories containing release snapshots of Xyce from our tarball releases. There is no prohibition against people outside of our group doing that once they obtain the code from our site. However:

  • None of these repositories is an official repository maintained by the Xyce team. Only the unmodified source code downloaded from our own web site our our own GitHub repository represents the latest version of Xyce supported by the team.
  • The repositories often contain outdated versions of the code. We have seen some that have not been updated in over five years.
  • If you take it upon yourself to create your own repository containing a copy of Xyce you obtained from a tarball, please do us the courtesy of keeping it up to date (we release about every six months), and please delete it when you decide you are no longer interested in maintaining it.

Your registration page is broken, it keeps giving me an error.

This likely means that your web browser is not permitting javascript to run from our web site, and so you can’t see that there is a “CAPTCHA” on the page. We employ a CAPTCHA to reduce the likelihood of malicious automated access attempts.

  • Enable javascript for our site, and the CAPTCHA will appear.
  • Some ad blockers appear to disable javascript for our site. If you have enabled javascript and you still don’t see the CAPTCHA, try disabling your ad blocker.
  • Once the CAPTCHA is visible, be sure to follow its instructions and the registration will work.
  • If you are concerned about the safety of the CAPTCHA we use, please see the Google reCAPTCHA web site for more information.

I have some code I wrote for Xyce that I think will be interesting to others. Can I give it to you under the terms of the GPL?

Perhaps, but it is complicated.

While we are pleased that we have been granted permission to release Xyce to the open source community, the primary reason for Xyce’s existence and continuing development is to fulfill certain R&D and mission requirements at Sandia National Laboratories. As an in-house circuit simulation tool, there are versions of Xyce that are not approved for open source release; these versions are often provided under other licenses to partner laboratories, government agencies, or contractors. The terms of the GPL do not apply to our own use of our own code.

This would change if we were to accept GPL code from a third party. We would have to ensure that any external GPL code is never included in any version of Xyce distributed under the terms of any license other than the GPL; creating derivative works that are not also licensed under the GPL is a violation of the terms of the GPL. This does not mean we would never accept such code—there may be compelling reasons for us to do so. However, we would take with it the burden of separating the closed-source versions of code from the GPL contributions. This burden could be particularly high, depending on the affected part of the code, and we may not have the internal need/funding to support the effort.

Therefore, if you wish to contribute code to Xyce—and we feel that your code would help us—we will likely ask you to provide it to us under an open-source license other than the GPL, such as the Apache 2.0, MIT, or BSD.  In this way, we could continue to use your code in our internal versions, but your code would still be open source and available for everyone.

It is for this same reason that we may not be able to accept “pull requests” on GitHub.

Are you aware of the “chip music” group xyce?

Yes, though we note the two groups came up with the name independently (the music duo started about six years after the code). We are fans.

I am having trouble building Xyce. Can you tell me what I’m doing wrong?

If you are having trouble building Xyce, the problem is usually due to missing dependent packages or incorrect “configure” invocation. The Xyce team is generally unable to help with system-specific details for any operating systems other than those we support internally, but the team may be able to help you if you provide:

  • The exact “configure” command line you used to configure Xyce.
  • The “config.log” file produced by configure.
  • The output of “make”.

If you are having trouble building Trilinos, the issue is often the same—missing dependent packages or incorrect invocation of “cmake.” We might be able to help you if you provide:

  • The exact cmake command line you used to configure Trilinos.
  • The console output from cmake.
  • The output of “make”.

If you are attempting to build Xyce on Cygwin, please see https://www.youtube.com/watch?v=-e0YcZ6bchU.

Another common issue is attempting to build Xyce with a newer version of Trilinos than the version against which the Xyce release was tested.  See the Building Guide webpage for more information.

I ran the Xyce Regression test suite, and it exited with some errors.  Is this something to be worried about or can I just ignore it?

The test suite will pass all tests with our supported builds, but some tests are so sensitive that they may fail in subtle ways on new platforms, especially on 32-bit architectures.  See the Running the Xyce Regression Suite page for more details.

I think I found a bug. How can I report it?

The team appreciates bug reports from users and will try to address bugs that are reported to us. Posting to the Google group is the best way to report them at this time, as your report (and our response) may be of value to other users. Please provide the following information at a minimum:

  • The operating system on which you discovered the bug.
  • The simplest netlist possible that can be used to reproduce the problem.
  • The command line you used to run Xyce on this netlist.
  • The exact error message produced by Xyce, or if Xyce produced incorrect results, a description of how Xyce’s output is incorrect.
  • The configure invocation you used to build Xyce.

I tried using a netlist that worked just fine in HSpice/ngspice/PSpice or some other simulator, and Xyce gave an error message about syntax.

Xyce is primarily compatible with basic SPICE3F5 syntax, with a large number of extensions that were requested by Sandia users to add some PSpice compatibility. While the Xyce team has tried to support some syntax extensions from other simulators, it is not 100% netlist compatible with any other simulator. However, the XDM netlist translator, available on the Downloads page, can help with translating from HSpice and PSpice. The XDM Users Guide has guidance for translating netlists and PDKs. Also, consult the Xyce Reference Guide for complete documentation of supported syntax. The Xyce Reference Guide also has a section on translating syntax between other simulation formats, such as PSpice, and Xyce.

Does Xyce come with a parts library? 

No. Xyce is only the simulation engine.

Does Xyce support computation of direct or adjoint sensitivities in transient runs?

Yes, as of Xyce Release 6.5.

Is there a Python interface for accessing Xyce libraries through a Python script?

No. However, the independently developed PySpice module provides an interface that can call a Xyce binary directly.

Is there an interface for co-simulation with event-driven (i.e., digital) simulators?

We do have an API in the Xyce::Circuit::Simulator class that could be used for this purpose, and there was work several years ago to do just that, but it is not currently used by any open source software. The Xyce team is not currently working on developing a link to any other event-driven simulators. If you are interested in developing a co-simulation interface we may be able to provide guidance regarding use of the API.

I would like to obtain slides or downloadable video of the Xyce class that is on the web site.

Unfortunately, we are unable to provide this class in any form other than the streaming video on the web site.

I want to develop a compact model for Xyce. Is there documentation on how to do so?

There is some documentation on how the device model package is organized and how to create a device model in the project’s Doxygen documentation. This may be found in the “docs/doxygen/html” directory of the Xyce source tree. There is also a tutorial on how to import simple Verilog-A models into Xyce, and a Users Guide on the Xyce/ADMS Verilog-A compiler tool.

I can’t get a certain Xyce syntax to work.  

Xyce syntax is documented thoroughly in the reference guide, and many types of special guidance are provided in the users’ guide. 

In addition to reading the Users’ Guide and Reference Guide, the Xyce Regression Suite has a wide range of working examples in subdirectories under Xyce_Regression/Netlists.  For example, the “Netlists/VPWL” directory has two example .cir files that illustrate the syntax for PWL (piecewise linear) voltage sources.  The corresponding correct .prn files are then in “OutputData/VPWL”.

If you still have trouble after checking your syntax, please contact us if you think you found a Xyce bug.

I can’t print lead currents for all Xyce devices.

Some devices such as inductors and voltage sources have associated with them additional solution variables (“branch currents” or “branch variables”) that can always be printed using the “I(devicename)” syntax or used in expressions.  In addition to these two special cases, other devices may provide access to the currents flowing into or out of their connecting nodes as “lead” currents that are computed in a post-processing step as quantities derived from solution variables.

The “lead current” method of printing from devices in Xyce is done at a low level with special code added to each device; the method is therefore only supported in specific devices that have this extra code.  The Xyce Reference Guide has a table (Features Supported by Xyce Device Models ) that lists which devices support lead currents.  If .PRINT I(Y) doesn’t work, for a device called Y, then you will need to attach an ammeter (zero-volt voltage source) in series with the device and print the ammeter’s current instead.

Are wildcards (*) supported on Xyce .PRINT lines?

There is partial support for V(*) and I(*), which print all netlist accessible voltage nodes and all branch variables, respectively.  Lead currents (as described in the last question) are not included in I(*) output.  Please see the .PRINT section of the Xyce Reference Guide for more detail.

Do Xyce expressions handle complex numbers?

Yes, as of Xyce Release 7.2.

My simulation fails (typically with a time-step too small error) when I use an IF statement in a controlled source definition.

This is a known issue that is typically caused by “infinite-slope transitions” in source definitions.  The Users Guide section on “Guidance for Analog Behavioral Modeling Usage” provides an example of how to fix this issue.

I am trying to simulate a netlist that contains two kinds of simulation (such as .TRAN and .AC)

A netlist with two .print lines (such as .print ac file=file1.prn v(1) and .print tran file=file2.prn v(1)) will run in Xyce.  However, Xyce currently doesn’t handle multiple analysis types in the same netlist.  In this example, it will only output the second file (file2.prn).

My netlist has a Switch device in it. It runs in ngspice but not in Xyce.

The problem may be that the Ron parameter in the switch is zero. Please consult the Reference Guide section on the Voltage- or Current-Controlled Switch.

My simulation runs in serial but fails to run in parallel.

For problems of moderate size, it may be helpful to run a parallel build of Xyce with the linear solver set to KLU (a direct solver). That is the so-called “parallel load, serial solve” option.  

  • You can set this option by adding this line to your netlist: “.options linsol type=klu”, or by adding the “-linsolv klu” to the Xyce command line. While the linear solve will happen in serial, the rest of Xyce’s behavior will be parallel, including all the device evaluations used to set up the linear system. This won’t speed things up as much as a fully parallel solve, but you should see some improvement.   
  • Parallel Load/Serial Solve is the default behavior of a parallel build of Xyce for problems with fewer than 1001 unknowns. If your problem is larger than that, a parallel build will run with a parallel, iterative solver by default unless options are given to specify a serial, direct solver.

Iterative solvers (like AztecOO) can require more tuning than direct solvers (such as KLU), and will require a preconditioner. The ideal choice of preconditioner is very problem dependent. There is a list of possible options in the “Guidance for Running in Parallel” chapter (Chapter 10) of the Xyce Users Guide. 

Are there source RPMs available for Xyce?

No, the Xyce team does not distribute source RPMs. We only generate the source code tarball that is on the xyce.sandia.gov site. The only RPMs provided are the binaries.

Did you forget to gzip the .gz files on the Downloads Page?

This gets reported to us from time to time.  No, we did not forget to gzip them, and those files are indeed in .gz format on the server. If you find that the files are not zipped when you download them, it is because some browsers, proxy servers, or ISPs decompress the files on receipt, but don’t rename them when they do it. There are sites on the web indicating that the Safari web browser is known to be one that does this. Some of these sites even offer suggestions for how to disable this feature.