Announcing the Open Source Release of the Xyce Circuit Simulator

[erkeiter]

Announcing the Open Source Release of Xyce 6.0

November 4, 2013‚ Xyce, Sandia National Laboratories' SPICE-compatible parallel circuit simulator, is available for free public download for the first time. Xyce has been developed internally at Sandia National Laboratories and funded by the National Nuclear Security Administration's Advanced Strategic Computing (ASC) Program. By open-sourcing Xyce, the code team hopes to foster external collaborations and solicit feedback from the simulation community.

Parallel Implementation
Xyce was designed as a parallel simulation code. Primarily, the parallelism is based around a message-passing implementation (MPI). Parallel scaling is very problem-specific, but for certain problems Xyce has shown scalability out to hundreds of processes.

Xyce is not SPICE
One of the goals of the Xyce development team has been for Xyce to be SPICE-compatible. However, Xyce is not a derivative of SPICE. It was designed and written from scratch.

Device Model Support
As a SPICE-compatible tool, Xyce supports a canonical set of compact models, including the various BSIMs, PSP, VBIC and FBH. Additionally, a large number non-traditional models are implemented, which support neuron simulation and reaction networks. Behavioral modeling is supported by a powerful expression library, and Verilog-A models can be incorporated with a model compiler.

Analysis options
As a SPICE-compatible tool, Xyce supports standard analysis methods such as steady-state(DCOP), transient(TRAN), and small-signal frequency domain (AC). A number of more exotic analysis methods have also been implemented, including Harmonic Balance (HB), Multi-Time PDE (MPDE), and model-order reduction methods (MOR).

Solvers
Xyce uses the Trilinos solver library, an open-source solver library also under development at Sandia. Trilinos is an effort to develop and implement robust algorithms and enabling technologies using modern object-oriented software design, while still leveraging the value of established libraries such as PETSc, Metis/ParMetis, SuperLU, Aztec, the BLAS and LAPACK. In addition, a number of circuit-specific solvers have been developed for Xyce, specifically, including the KLU direct solver.

C++ code design
Similar to Trilinos, Xyce is written in C++, with modular, flexible design as a goal. Where appropriate, Xyce applies abstract interfaces to enable easy development of different analysis types, solvers and models.

Portability
Xyce is supported on Unix-like operating systems such as Linux and OS X, and on Windows.

Opportunities
The goal of the Xyce development team is to seek new opportunities and solicit feedback. Our experience has been that new collaborators, new benchmarks and external feedback can be a valuable starting point for code improvements.

Open Source
Xyce is available under the open-source license GPL version 3.0.

Download
For more information about Xyce, and to download the code, visit the new Xyce Home Page at http://xyce.sandia.gov.

Sandia National Laboratories is a multi-program laboratory managed and operated by Sandia Corporation, a wholly owned subsidiary of Lockheed Martin Corporation, for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-AC04-94AL85000.
<script src="//platform.linkedin.com/in.js" type="text/javascript">
lang: en_US </script> <script type="IN/Share" data-counter="right"></script>

 

[Daniel Payne]

Hmm, this looks very interesting to me. I just visited their web site and requested permission to download it. My only barrier is that it appears that I actually have to compile the source code after installing dependent libraries, etc. Yuck, I just wanted to download a .DMG file for my Mac OS X laptop.

Has anyone else downloaded, compiled and tested Xyce yet?

Wednesday update:

• Last night I updated Xcode on my Mac to include Command Line Control
• Downloaded and installed MacPorts
• Started to install gcc (sudo port install gcc48), however after 12 hours it isn't completed!

Here's the Xyce Building Guide.

 

[Daniel Payne]

OK, I finally got gcc to install, however now I cannot install fttw-3:

% sudo port install fttw-3
Error: Port fttw-3 not found

 

[LinkedIn]

Javid Jaffari
Thanks for the news. A few thoughts:
- Is there a plan to setup an issue tracking system, for requested features, improvements, and bug fixes?
- Also a set of QoR benchmarks for runtime/mem/accuracy would be very helpful. Ideally, a centralized cloud to evaluate the qor of submitted jobs.

 

[LinkedIn]

Eric Keiter


Hi Javid,

- We have been doing issue tracking internally (using bugzilla) for some time. We have discussed setting up something externally but haven't gotten around to it yet. I think partially we're waiting to see what the response is from the outside world. If nobody downloads it, etc, then there isn't much point in setting up an external issue-tracker.


- We are releasing a lot of our regression test suite (the parts we're allowed to release, that is) along with the Xyce source code. That doesn't get directly at your QoR question, but it is a start. Benchmarking EDA tools is a bit tricky, for a number of reasons. We have attempted to publish guidance on how to optimally run Xyce as part of the documentation.

 

[erkeiter]

Daniel, thanks for trying out Xyce.

We did have a discussion about whether or not to post the source code, or to also include binaries. To our internal users we do provide things like *dmg files. However, our web people were concerned about bandwidth and disc space, so initially we just went with a source distribution. The binary files, of course, are much larger than source, and platform-dependent.

Having said that, we're still learning how to do this. I think we might be open to distributing binaries in the future, but we'll need to have a discussion about it.

Regarding your port install error with fftw. hmm. If you do "port list" and pipe the results to a file, you should find fftw in the list somewhere. In my own macports distribution both fftw 2.1 and fftw 3.3 are available.

Another option is to just install fftw by hand instead. FFTW Home Page

 

[Daniel Payne]

Oops, I had a typo, now I can download "fftw-3". Sorry for the false alarm.

 

[tty2]

I'm really excited about this and can't wait to start seeing things like integration with major CAD packages, as well as someone tacking on a nice GUI for student use. I could see this becoming the replacement for LTSpice as the default simulator for university students on a budget.

I'd always request that the project get put on GitHub so we can contribute in a social manner, however.

 

[Daniel Payne]

OK, I'm a bit farther in the install however I get errors when using the script with cmake:

CMake Error: your Fortran compiler: "gfortran" was not found. Please set CMAKE_Fortran_COMPILER to a valid compiler path or name.
-- Configuring incomplete, errors occurred!

When I look for Fortran I get:


% sudo port list | grep fortran
fortrancl @0.1alpha4 devel/fortrancl
py-fortranformat @0.2.3 python/py-fortranformat
py26-fortranformat @0.2.3 python/py-fortranformat
py27-fortranformat @0.2.3 python/py-fortranformat
py31-fortranformat @0.2.3 python/py-fortranformat
py32-fortranformat @0.2.3 python/py-fortranformat
py33-fortranformat @0.2.3 python/py-fortranformat

netcdf-fortran @4.2 science/netcdf-fortran

 

[tvrusso]

This appears to be an omission in the Building Guide, where the cmake invocation in Figure 3.1 is really just a copy of what is required on Linux, but which needs to be modified for other platforms. We provided this specific guidance for each platform in the section detailing compilation of Xyce, but did not add platform-specific guidance for the Trilinos build.

Consulting with the person who provided the Macports instructions, there are a few tidbits that should have been in the document but were overlooked:

1) On Macports, gcc (and gfortran, which is part of the gcc install you have already done) installs itself with a suffix, and that suffix is "-mp-48". So, when building Trilinos, you should modify the invocation in Figure 3.1 to read:

CMAKE_C_COMPILER=gcc-mp-48 \
CMAKE_CXX_COMPILER=g++-mp-48 \
CMAKE_Fortran_COMPILER=gfortran-mp-48 \

While we corrected the compiler specification for Xyce itself in the building guide errata, we failed to mention this also needed to be done in the Trilinos CMake invocation. We'll get that information into the errata ASAP.

2) There is apparently also a command you can invoke to cause Macports to create an alias for the three compilers: sudo port select --set gcc mp-gcc48
This will allow you to invoke the gcc, g++ and gfortran compilers without the "-mp-48" suffix.

3) You must also remember to modify the "AMD_LIBRARY_DIRS" and "UMFPACK_LIBRARY_DIRS" variables to have the value "/opt/local/lib", and change the "TPL_AMD_INCLUDE_DIRS" and "TPL_UMFPACK_INCLUDE_DIRS" to have the value "/opt/local/include" (this is correctly documented on page 18, I mention it just for completeness)

I apologize for the missing information in the building guide. We tried to get as many system-specific details in there as we could, but some clearly slipped through the cracks.

 

[Daniel Payne]

Thanks for the info, I've updated my script however it still fails:

-- Check for working Fortran compiler: gfortran-mp-48
CMake Error: your Fortran compiler: "gfortran-mp-48" was not found. Please set CMAKE_Fortran_COMPILER to a valid compiler path or name.
CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Check for working Fortran compiler: gfortran-mp-48 -- broken
CMake Error at /opt/local/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:54 (message):
The Fortran compiler "gfortran-mp-48" is not able to compile a simple test
program.

 

[tvrusso]

Bleah.

I'm very sorry you're having this trouble. Perhaps your install of macports has installed gcc and gfortran with a different prefix than our Macports maven has.

Since the bash shell has command completion, it may be possible to figure out what name gfortran has been installed under by macports. Can you try typing "gfort" and hitting tab, to see what options it comes up with? Since you successfully installed gcc 4.8, and the gcc package is *supposed* to install fortran at the same time, it should be detectable that way. Typing "gcc(tab)<tab>" and "g++<tab>(tab)" would also provide useful information that we may be able to use to help you get past this.</tab></tab>

 

[Staf_Verhaegen]

I'd always request that the project get put on GitHub so we can contribute in a social manner, however.

I think even github, sourceforge or other sites can be used for distributing binaries of open source project without hosting the code repository there. At least it is possible with sourceforge.

 

[tty2]

Right but I don't think there's an issue with binary distribution, I'm specifically suggesting they -do- post code and allow community development.

 

[tvrusso]

Allowing community development is definitely on our radar --- it is, after all, precisely the point of licensing it under GPL. At this stage, though, we had enough work cut out for us just getting the code released open source at all, and had to take a baby step first. Putting it on github or sourceforge may ultimately happen if there is sufficient interest by the open-source community.

 

[tvrusso]

The Xyce team is happy to announce that we are now able to provide executable versions of Xyce for a small number of platforms (the platforms we support internally):

- RedHat Enterprise Linux 6 (and related systems like Fedora and CentOS) with RPM installers for serial and parallel. These RPMs automatically install all packages required for Xyce to run in either serial or parallel.
- Mac OS X with DMG installer for serial and parallel. The serial version is completely self-contained and ready to run. The parallel version requires additional work to install, and these steps are documented on the site.
- Microsoft Windows, serial only, with an NSIS self-extracting archive, self-contained and ready to run.

Source code distribution continues to be our primary focus, but since we already had these executables built we are providing them as a convenience.

Xyce may be downloaded at http://xyce.sandia.gov/

 

[Daniel Payne]

Wow, thank you much for creating the Mac OS X installer, it worked just great. Are there any demo netlists and libraries to test out with Xyce?

 

[tvrusso]

There are no parts libraries --- Xyce is just the simulation engine, just as SPICE3F5 or ngspice are. But there are hundreds of demo netlists in the regression test suite. The netlists at the top level of the regression suite's "Netlists" directory tend to be pretty small and basic, but there are some larger ones in the "Certification_Tests" subdirectory.

While it's possible to run individual tests from the suite by hand, there are instructions for running the complete regression suite on the web site. Doing so does require Perl, though. You'd have to install that from MacPorts.

For a challenging netlist that other open-source simulators have a hard time running, take a look at Xyce_Regression/Netlists/CircuitSim90/MOS2_LARGE/voter.cir. This takes Xyce some 8-10 hours to run to completion, but ngspice cannot run it at all, and while gnucap can obtain an operating point, I have yet to see it produce any output after t=0 (I've had it running for over 8 hours already).

 

[harpoon]

This looks very interesting ... will it ever replace my Spectre or Eldo (or any of the major players) ?

Can it deal with foundry supplied model files ?

 

[erkeiter]

This looks very interesting ... will it ever replace my Spectre or Eldo (or any of the major players) ?

Can it deal with foundry supplied model files ?

Regarding the first question, in the short term, probably not. Xyce was not developed with a GUI . We've looked into integration with commercial tool flows, but that sort of thing often depends on having a license from one of the major vendors to use their API, and we probably couldn't release that as open source.

Having said that, it has a better chance of correctly reading a foundry model file than (for example) spice3. They sometimes will need a little tweaking, to make sure the correct level numbers are being used, etc. We do have some experience with this, mostly for files in Hspice format.

Most of our internal users, in addition to Xyce, also use a commercial tool of one kind or another. So, we've added compatibility with other tools on a case-by-case basis, depending on user demand. So, for example, we support .MEASURE (of Hspice), but only support the parts of .MEASURE that have been requested thus far. We don't have a lot of users that are using Spectre, so that hasn't come up (and would be a bit harder as its a further departure from the SPICE netlist language). We do have a lot of users that are using Hspice/Pspice/SmartSpice, so as needed we've added features of those tools. In the current implementation (Xyce v6.0) the netlist parser is a superset of all these *Spice-compatibilities, and of course it is impossible to do this forever, because some features conflict. For example, the U-device in Pspice is a digital device, but the U-device in Hspice is a transmission line.

As a result, we have on our roadmap a plan to replace the parser with a more abstract data model, that would (in theory) make it easier to have different parsing modules to handle Hspice/Spectre/Eldo/etc in more fully compatible way. But, this is still a work in progress.