Nutmeg support and Verilog-A shared libraries

[Francesc Serra-Graells]

Dear Xyce developers,

First of all, let me congratulate you for Xyce. It is a real piece of art.

I am maintaining an academic PDK (APDK) for teaching purposes at university, which employs Glade (schematic and layout edition, netlister, DRC, LVS, PEX 2D/3D) and SpiceOpus (SPICE3 + XSpice HDL + optimize tool + waveform viewer):

http://www.cnm.es/users/pserra/apdk

Currently, I am considering to switch from SpiceOpus to Xyce. In this sense, can you tell me if the following items are in your mid-term roadmap?

1. Nutmeg Support

SPICE3 simulators usually come with Nutmeg scripting language. This capability is quite interesting in order to work with several circuits, modify device properties during optimization, manage several analysis and mix their simulations results. Here are some code examples:

.control

* Managing several circuits
source ckt1.cir
source ckt2.cir
select ckt1

* Modifying device parameters
let @m1:xopamp[w] = 1u

* Managing several analysis
op
tran 1n 5u
let fom = tran1.sr*@cload[c]/op1.pd

.endc

It would be great if Xyce could include this feature in the future...

2. Verilog-A Shared Libraries

Apart from the parallel simulation of large circuits, I am also interested in Xyce for its Verilog-A support.

Currently, my students are modeling with XSpice HDL (C code) and they compile their code models separately from the simulator core, so the corresponding binary libs (*.cm) can be loaded into the simulator on the fly.

I understand that Xyce is able to use shared libraries from compiled Verilog-A code models, but it looks like it requires the entire simulator to be previously compiled with --enable-shared --enable-xyce-shareable options.

Are you planning to distribute Xyce binaries under this compilation scheme?

Thanks in advance for your kind answers.

Best regards from Barcelona,

Francesc Serra-Graells

[xyce-users]

Francesc,

Thank you for your interest in Xyce, and for your kind words about it.  Both of your questions are pertinent to our development plans.

I'll answer the second one first, about shared library support.   We do plan to make this feature available in release binaries at some point.  At the moment, it isn't clear if we will get it done in time for our next code release, which is Xyce 7.5.    But it is something we plan to do.    In the meantime, one possible solution for you ( if using Xyce on linux or osx ) would be to use spack to install Xyce. 

Regarding nutmeg support.  I'm going to give a more vague answer to this one.

At a high level we've been discussing this sort of capability.  We're currently in the process of adding an optimization library to Xyce, which could (in theory) perform the same sorts of optimizations that SpiceOpus can do.   However, fully specifying an optimization problem from the input file is an issue we are still trying to figure out, and one possible option for this is to support the nutmeg language or some other scripting language.

There are a bunch of inter-related issues to this.  One is that Xyce was initially written (decades ago) to only support transient simulation, so we didn't design it to support multiple analyses in the same input file.    So, that is something we want to do but it requires some structural changes in the Xyce source.  The code is much closer to being able to do this than it was 10 years ago, but it isn't there yet.

Another related issue is that we've worked on making it possible/easier to use Xyce with Python.  There have been various activities with this, including the Xyce-PyMI interface, documented here:  https://cfwebprod.sandia.gov/cfdocs/CompResearch/docs/Xyce-PyMi-Guide.pdf

So, another possible outcome is, rather than supporting nutmeg, to instead use python as the scripting and/or integration language.

So, this is all under discussion and we haven't quite converged on what we plan to do.  But at a high level, supporting scripting style commands in the netlist is a good idea and something I'd like us to do.

regards,

The Xyce Team

[Francesc Serra-Graells]

The Xyce Team,

Thanks a lot for your detailed answer and tips.

In my opinion, choosing Python over Nutmeg is really a good strategy. We are all already using Python as the de-facto user interface language in many IC design tools to script from layout pCells to DRC rules.

I will surely try Xyce 7.5...

Best regards,

Francesc Serra-Graells

El dia dimecres, 16 de març de 2022 a les 18:20:21 UTC+1, xyce-users va escriure:

[Marcel Hendrix]

Nutmeg flow control (as I know it from ngspice) is horrible, but it gets the job done. 

Making the simulator internal data structures available through an API would enable to use

arbitrary scripting engines. It is a lot of work, though.

-marcel

[Kevin Cameron]

Xyce is a bit big and cumbersome, I would recommend migrating to a pluggable shared-library approach for things like translators and Verilog-A.

Compiled-in Verilog-A models are guaranteed suboptimal, you really want to do per-instance compilation for that stuff, and that makes the main build easier.

As part of IEEE P2427 (defect simulation/analysis) it's useful to have that under software control (like Python scripting), so you can switch between models as you go. Hooking Python into any C++ simulator is just a few days' work. You can probably parse Nutmeg scripts with Python without too much effort.

With a plug-in approach you can decouple the plug-in development from the core development and that makes it easier for people to fix things like the HSpice and Spectre translators at their own speed, or add new ones.

If anyone else is interested in making all that happen, maybe we can team up.

BTW, a friend asked me about integrating IRsim, and that's seems like something that could be integrated as a plug-in, and I've done some work already -

http://cameron-eda.com/2020/06/03/rolling-your-own-ams-simulator/

http://opencircuitdesign.com/irsim/reference.html

It's not hard to feed IRsim a Xyce (transistor) netlist (more Python), and you can patch it in to replace analog modeling as-you-go as a digital acceleration technique - disabling chunks of matrix calculation isn't that hard (vs adding stuff).

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/4d22d9d6-f48d-4d2b-83e6-f7de98f4c79bn%40googlegroups.com.

[xyce-users]

I just wanted to add a little more information about your request regarding our distribution of binaries and verilog-a support.

We've been looking into how we could bundle Xyce binaries better than we currently do and have made a lot of progress,  but it probably won't be available in our 7.5 release.  And if anything, the first system that we'll support that way will probably be Mac OS X.

There are significant impediments to distributing a version of Xyce that supports shared libraries, the biggest of which is that we are building Xyce for Linux on an RHEL7 system, which has old compilers as the default.  On this system we have to use a combination of the Intel compiler and the "RHEL7 developer toolset" version of gcc8 --- neither of which is typically available to a user without some expense and effort.  And as it turns out, even if we were to distribute a build of Xyce that supported shared libraries, a user couldn't make use of the extra capability unless they also had these same compilers installed --- at least at the moment the verilog plugins must be built with the same compiler toolchain that built Xyce.

By the time you get everything you need to make use of a prebundled Xyce binary with shared library support, you'd almost have done as much work as compiling Xyce from source yourself.

The problem is less severe on OS X, because we're already using the system compiler "clang", but there are smaller issues there that need to be addressed.

We still intend to push on this issue, but it's turning out to be more complicated than we had thought and can offer no promises that it will be available at any particular point in the future.  So for at least the near future, your only option for getting access to the Verilog-A plugin capability will be to build Xyce from source as Eric says, or using the non-standard "spack" approach previously mentioned and that is documented somewhat in the PyMi report he linked to.  Honestly, all that is getting done by that spack approach is automating the build from source.

Another option you might look at is this meta repository that tries to do a similar automation, but using only native system tools and no non-standard package management:  https://github.com/tvrusso/XyceBundle

[Justin Fisher]

Just a quick aside regarding GCC. NGSPICE needs GCC 11 I installed this on Red Hat 8 using devtoolset 11 which was a quick and easy thing to do.

There's a howto somewhere in the latest NGSPICE download from the git repository.

--
Justin.

[xyce-users]

Ah.  That is very interesting, as we had been under the impression (given how long it took for Sandia to make it available to our group as part of our RHEL7 installs) that it was an expensive add-on to RHEL that other users might not be willing to get at.

If it is indeed quick and easy to obtain, we may be able to distribute a gcc-built binary in shared library configuration for users that are willing to jump through that hoop.

Thank you for the pointer.  I'll go look at how ngspice is telling users to obtain the devtoolset.

[Justin Fisher]

Ok, I'm being lazy!

I initially couldn't find the document regarding devtoolset (I wrote it). But I have since done a comprehensive search. Included here, in RTF format.

--
Justin

[xyce-users]

Yes, I did have to dig around more than I'd have thought necessary, but I did manage to find it on the ngspice "download" page at https://sourceforge.net/projects/ngspice/files/ng-spice-rework/36/ in PDF form.

That still suggests to me that one has to be subscribed to the devtoolset as an RHEL7 user, which may involve extra expense.  But if folks are using Xyce on RHEL7 other than us and are relying on our binaries, then there may be a path forward for us to provide shared builds.  They would absolutely need devtoolset-8 were we to do so.  Unfortunately, I cannot test out the procedure as our systems are tightly controlled by corporate IT, so cannot write a Xyce-specific document like yours.