Work in progress: New ADMS replacement

[Juan Sanchez]

Hello,

I am working on an ADMS replacement named PYADMS.  It takes the Verilog-A parser from ADMS and generates a JSON representation.  This representation can then be manipulated in Python.

I have started translating the original Xyce admst into Python script.  An example file of that is here:

https://github.com/tcaduser/Xyce/blob/pyadms1/utils/ADMS/pyadms/xyce_implicit.py

Comparing the top of the file to the bottom, you can see that the Python version is much more concise that the admst.

Anyway, before I spend too much more time on this, I wanted to see if there would be any interest in this endeavor from other members of the Xyce community?

This is very much related to efforts in my professional career, where I have leveraged Python as the the driver for compact model code generation in a production SPICE simulator.

Regards,

Juan

[Murat H Eskiyerli]

Hello,

I am developing a Python based schematic and layout editors called Revolution EDA. Its file format is also JSON. One of the functionalities is creation of a symbol from a verilog-a module and its addition in the netlist. I wonder if we could converge.

Regards,

Murat Eskiyerli 

Murat H Eskiyerli

---

From: 'Juan Sanchez' via xyce-users <xyce-...@googlegroups.com>
Sent: Saturday, December 16, 2023 6:07:58 am
To: xyce-users <xyce-...@googlegroups.com>
Subject: [xyce-users] Work in progress: New ADMS replacement

--
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/5a9593da-53c3-4b22-ae10-2f0a2c4a0b7dn%40googlegroups.com.

[Kevin Cameron]

Hi Juan,

This came out recently -

https://hackmd.io/@DSPOM/HkyvBoTZv

ADMS was a bad idea, I don't think a Python version will be an improvement, and I generally consider JSON an anti-pattern.

That said, if you fancy re-implementing Verilog-A as native Python language for use in math modeling/AI, I'd be interested.

Kev.

[Juan Sanchez]

Hi,

OpenVAF seems like a nice idea.  It appears that their may be some licensing issues with the GPL, which I have not been able to figure out:

https://github.com/pascalkuthe/OpenVAF/issues/95

I also prefer an approach where I can see the generated source code, for debugging purposes.

The purpose of the JSON is to separate the parser from the implementation, so that the other pieces are free of the GPL in their implementation.

Then, each vender can then implement their own compact model generator, tailored specifically to the features of their circuit simulator.  It is their choice to leverage any existing components of the framework I am wanting to develop.

An example json file is here:

https://github.com/tcaduser/Xyce/blob/pyadms1/utils/ADMS/examples/EKV/ekv-2.6/ekv.json

Also, rewriting the parser into something GPL free would be a substantial effort, which can come later.

The loader then converts the JSON into a collection of Python classes, which are possible.  Alternatively, others can choose to develop their own JSON processor in the language of their choice.

Regards,

Juan

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/52f971d4-9682-419a-b82f-ce0a58ba3e8d%40gmail.com.

[Juan Sanchez]

Thanks for your interest.  Please feel free to contact me at this email or via the project:

https://github.com/pyadms/pyadms

Regards,

Juan

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/DU0P251MB07196928D219EE7E6A487887F892A%40DU0P251MB0719.EURP251.PROD.OUTLOOK.COM.

[xyce-users]

Hi Juan and everyone,

We've had some interactions with the group that develops OpenVAF and we've given them feedback on their OSDI interface.   Our plan is to eventually adopt the OSDI interface in Xyce, once we have the time to do so.

We are in the process, internally, of developing our own Verilog-A model compiler.   We plan to have that new code also support OSDI as well.  We were already committed to our internal project when OpenVAF was announced, and plan to continue that effort.    OpenVAF does seem like a very nice tool, however.

As we are planning to support the OSDI interface (and that interface is also being used by other open source codes), I would recommend you include that as an option in your new Python code.

Regarding Kevin's comment, about ADMS being "a bad idea";  I might agree with that, or I might not.  At the time that ADMS came out, there were no other open-source model compilers, and its release was synergistic with the general effort to standardize compact models around the Verilog-A language.    Before that, compact models were simply implemented in Spice3 C code, and weren't portable.  

Moving the compact modeling community to a high-level modeling language was a good development, even if the choice of language wasn't ideal, and even if the first open-source tool had some flaws.  As for ADMS itself, it has various design issues that make it difficult to work with, and it didn't (doesn't) support all of the Verilog-A specification.  If I had it to do over again we probably would have developed our own a long time ago, rather than adopt ADMS.    But anyway, one way or another, we're moving away from it as soon as we can.

thanks,

Eric

[Kevin Cameron]

The problem with ADMS is that it had a very narrow focus and missed a lot of the functionality of Verilog-AMS, but its adoption blocked development of better solutions. I wrote an open-source Verilog-AMS parser back before 2000, and I built the first compiled-code Verilog-A  for HSPICE back in ~ 1996. This stuff is generally well behind where it could be if folks actually cooperated. HSPICE was in Fortran, and the compiler did C, it did dynamic loading, so it was used to update the device models post release.

Also, you really want to do JiT compile for the models to take out all the constants, trying to come up with models that fit all sizes of transistors on all processes is a bad approach too, they only did it because everything was compiled in on the old SPICE simulators, ideally you just model for the individual processes and deliver that as Verilog-A in the PDKs.

Kev.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/3ea43f0f-896b-412f-9355-da8d9a869b56n%40googlegroups.com.

[Juan Sanchez]

Hello Eric,

Thanks for your response. It seems like osdi is the way to go. It
also looks to be a lot more straight forward than trying to translate
the admst algorithms. I will focus on implementing the osdi interface
in my project.

For all of its criticisms, ADMS was developed and had active support
of an industrial partner, Motorola, who were also kind enough to open
source it. And they (now NXP) still actively participate in the
development of the Verilog standard.

It seems that now is a good time for the open source community to
develop new systems. Having the leverage of Xyce, ngspice, and an
active developer (SemiMod), it would be interesting to see this OSDI
approach take off.

Regards,

Juan

> To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/3ea43f0f-896b-412f-9355-da8d9a869b56n%40googlegroups.com.

[Juan Sanchez]

I don't think ADMS blocked anything. It may have made it more
difficult for alternatives to enter the market, but now companies are
more receptive to open source solutions.

ADMS pain points are now impossible to ignore. XML/XSLT were once an
exciting technology, but I wish the developers had chosen something
else.

Anyway, I am not arguing for keeping ADMS. I am leveraging its
preprocessor and parser until my project is otherwise viable. Then I
can create a GPL free alternative.

A JIT compile is a question of semantics. I have worked with many
systems generating C code and calling a compiler under the hood. It
is the equivalent of systems handling everything in memory and
obfuscating the transformation in an opaque object. I would rather
have the C code.

Regards,

Juan

> To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/71ff4450-15a8-4c0c-8db1-b398855c7628%40gmail.com.

[Kevin Cameron]

ADMS aside, Verilog-AMS was never properly deployed either, Cadence
messed with the standards process, and it wasn't integrated with
SystemVerilog (before that went to the IEEE).

At this point I'm up for moving what is in Verilog-AMS to an extended
Python, since Python has a bunch of performance problems that could be
fixed with (better) JiT compile. A reason for doing that is that Python
gets used for AI work, and although neural networks could be described
in Verilog-AMS, nobody is likely to do that.

Kev.

[xyce-users]

Speaking of Python, Xyce already supports models written in Python via capability we call "PyMI" (or Xyce-PyMI).   This feature isn't yet included in production builds, but it can be enabled if you build Xyce yourself.  This was done to support machine learning based models, which are often developed in python and often use python libraries like PyTorch.

We have a report about Xyce-PyMi, which you can find here:

https://www.osti.gov/biblio/1813650

One nice thing about using Python for numerical calculations is that most of the underlying libraries (in numpy, etc) are written in fortran or C.  So those operations can be fast.  

The PyMi interface only requires that the user populate certain functions that Xyce needs to support a device.   (note, this was developed before we knew about OSDI, so it doesn't work with that).  

Also, it doesn't read Verilog-A.  However, if a new Ptyhon-based Verilog-A parser were to become available, it could potentially be used in a PyMi model.  It could be imported as a module.  So, that might be something to think about.

thanks,
Eric

[xyce-users]

I forgot to mention.  Regarding Python performance, another thing that can help is using a Python compiler like Numba.

Eric

[Juan Sanchez]

Hi,

I have started the osdi branch on my project and will start work on
with OpenVAF exemplary diode:
https://github.com/pyadms/pyadms/tree/osdi/osdi

as it shows a c implementation from the input verilog.

For testing, I will use ngspice and the verilogae python module from SemiMod:
https://github.com/pascalkuthe/OpenVAF/issues/108

I anticipate for this to take some effort, and everyone is welcome to join.

Regards,

Juan

> To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/3398600b-6b22-4049-a99b-7885a17cdcb5n%40googlegroups.com.

[Kevin Cameron]

Interesting stuff.

I've been looking for ways to implement digital-twinning in analog simulators, based on Bernard Widrow's work -

Adaptive Inverse Control, Reissue Edition: A Signal Processing Approach: Widrow, Bernard, Walach, Eugene: 9780470226094: Amazon.com: Books

SPICE model => Plant, behavioral/NN model => Plant Emulator.

I'm expecting Python will be the control language for that.

For NN-models to be portable you need a standard language like Verilog-AMS. After working with EDA companies and IC design houses for 30+ years, I'd say the chances of Verilog-AMS being fully adopted is zero unless I do it myself and give the stuff away, and it will still take decades more - Verilog-AMS is not a complicated language and we are 2 decades on from its creation.

My experience with Python in EDA so far is mostly cocotb, which I can highly recommend avoiding. It's a lot easier to do an extended Python with reactive threading and math modeling, proper debug and JiT compile - at least somebody is likely to use that, and I can make it faster than C++.

Kev.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/d92a1cd4-1537-4ad5-8642-5930ec1d62b8n%40googlegroups.com.

[Markus Müller]

Hi guys, Markus from SemiMod here.

One of the main advantages of OpenVAF (not mentioned here before) over any transpilation approach (which ADSM is, or pyadms as far as I can tell),

is that models compiled with it are highly optimized, leveraging state-of-the-art compilation techniques. This optimization is almost impossible to achieve with transpilation.

A main road blocker for using Verilog-A models in commercial PDKs was exactly this speed problem, which has never been overcome by anyone. So EDA vendors

have kept implementing stuff by hand.

Another issue is that it is very difficult to implement the whole standard when using a transpilation approach.

W.r.t. to debugging: Yes, a compilation approach is not so easy to debug. But how many users do that? And those could just use Verilog statements for

debugging, or dig behind the compiled model if necessary.

OpenVAF is under GPL and that will remain so. Our licensing issues are not related to this.

[Stefan Schippers]

I fully endorse what Markus says here.

I have had to deal (in my past VLSI designer career) with numerous behavioral models written in many different languages, and in so many cases even a few instantiations of those "small" models in a fullchip testbench were able to slow down the whole simulation or even worse make it fail due to convergence issues.

Writing well posed models that the simulator manages without problems is entirely in the hands of the programmers, however translating it to the fastest possible machine code is also a requirement. No source to source compiler or interpreted / bytecode solutions are ok from this perspective.

Wish you all a happy new year!

Stefan

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/cb85afeb-8bad-4a69-a213-b8a0833fefb2n%40googlegroups.com.

[Juan Sanchez]

Hello Markus,

Thanks for your input.

I didn't realize you were part of the project in your response on the
Github issue I created:
https://github.com/pascalkuthe/OpenVAF/issues/95

Can you state what the license is for the shared library that OpenVAF
produces or the OSDI header file? Are there any licenses requirements
placed by the use of OpenVAF on the generated shared library? It is
still unclear to me if OpenVAF creates additional requirements on
circuit simulators that include your OSDI header fle and load
libraries

PyADMS is only using ADMS to generate a JSON representation of the
post processed Verilog. It is not a "transpilation" approach, and
neither was ADMS. The xml scripts included with the software, and
implemented by Xyce and ngspice, did use transpilation.

Compact model developers need to debug their models, and Pyadms is
targeted toward them. I want to make it painless for them to move
from their in house approaches, or to incorporate PyADMS into theirs.

Regards,

Juan

> To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/cb85afeb-8bad-4a69-a213-b8a0833fefb2n%40googlegroups.com.

[Juan Sanchez]

Hello Stefan,

Happy New Year.

Thanks for sharing your input. Having worked on Verilog-A compilation
at multiple companies, I do know the importance of speed in the
compiled model. One company used ADMS, so I translated the xml
scripts to Python. I was able to add many features improving the
model speed of the compact model, using the internal hooks of the
circuit simulator to speed up the model evaluation. This was
difficult in the original ADMS, and much easier in a modern scripting
language approach. And that is what I am trying to do here.

Speed optimization is important, but so is having access to the
internals of the target simulator. That is why I support OSDI, but I
also support in house circuit simulation.

Regards,

Juan

> To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/34661911-5c8b-44af-9a65-2b6a05134590%40gmail.com.

[Kevin Cameron]

Most SPICE-like simulators are slow because they're trying to balance a lot of currents, and everything is connected to everything.

In reality only power electronics uses plain single transistors, and most circuits are built from functional blocks that have mostly signal flow behavior where you don't care about the internal currents, and things are only connected to a small number of other things.

In that scenario you can get away with something like ADMS if it is accurate, but all you do with it is digitally twin the block level circuits into something faster in the simulator (see Bernard's stuff). Signal-flow models break up the matrix and reduce the amount of work that actually needs a solver.

Since most big circuits are a collection of library parts there's plenty of opportunity to rip through the libraries and generate all the block level models you need ahead of time, although you can just spin off jobs to do it as you go.

Python fits in as the scripting language to use in the simulator to orchestrate making models and replumbing.

Experience with designers says they mostly don't understand Verilog-AMS and don't have the time to learn how to do this stuff manually.

The Cadence environment (Virtuoso) has a lot of awkward configuration management, which could be avoided if the simulator just talked to Open Access directly, and understood the designers intent better. In the above flow I would be creating Verilog-AMS behavioral models in the simulator and pushing them back into Open Access for future use (and portability). Most HDLs exist to make designs portable and enable plug-and-play among the simulators, but there are usually limitations to what any individual HDLs can do - RF/AMS is a bit of a no-mans land.

WSL on Windows means that you can now target Simplis and LTspice for replacement by Xyce (etc.) with PMIC/power being the target market. Bridging directly to Open Access is a plus in most design environments, since Simplis and TTspice don't do it.

Elsewhere on the commercial front: simulators like HSIM used in VCS-AMS tend to just compile in standard Verilog-A models, and don't recompile for the customers' use (to take out the constants), so they're a lot slower than they could be. They're also not a moving target since the EDA companies are very change-averse, displacing them isn't hard if you can work as a drop-in replacement, cost nothing and go faster.

Also, if you have access to commercial simulators, you can digitally twin from their behavior into (say) Xyce at block level, and never get involved in the PDKs.

Kev.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/cb85afeb-8bad-4a69-a213-b8a0833fefb2n%40googlegroups.com.

[Markus Müller]

Hi Juan,

frankly, I do not know what the license of the compiled model is. I do believe that it just remains to be the license of the compiled Verilog-A file.

But one would need to ask a specialist lawyer. We did not think about this, to be honest. The OSDI interface implementation is MPLv2.0 license.

If you ship OpenVAF separately, you just need to open up the source of the OpenVAF code. The simulator can remain proprietary.

If you modify OpenVAF, since it has GPL, you are free to distribute but need to disclose the modified OpenVAF code.

ADMS is transpilation as it generates source to source, then uses an actual compiler like gcc. Correct me if I am wrong.

Best regards,

Markus

[Juan Sanchez]

Hi Markus,

I am not a lawyer, and laws depend on jurisdictions. My non
professional opinion, based on my research (including the GPL FAQ) is
that:

Any piece of nontrivial object code that you insert into the shared
library is under the copyright of the OpenVAF project. It is then
subject to the license terms that your project chooses. It is also
subject to the license terms of any other libraries you are linking
into the shared object.
Anyone loading the OSDI library into a simulator is creating a
combined work, subject to the license terms of all of the components.

ADMS fits your definition of transpilation. However, ADMS is more
involved than a pure source to source transformation, and in my eyes
fits the definition of a model compiler. This is with respect to its:
dependency analysis
symbolic differentiation
matching the circuit simulator API
etc.

Regards,

Juan

> To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/18b59e31-00c2-4220-8387-3160f86b9d56n%40googlegroups.com.