Giter VIP home page Giter VIP logo

openvaf's Introduction

OpenVAF


OpenVAF is a Verilog-A compiler that can compile Verilog-A files for use in circuit simulator. The major aim of this Project is to provide a high-quality standard compliant compiler for Verilog-A. Furthermore, the project aims to bring modern compiler construction algorithms/data structures to a field with a lack of such tooling.

Some highlights of OpenVAF include:

  • fast compile times (usually below 1 second for most compact models)
  • high-quality user interface
  • easy setup (no runtime dependencies even for cross compilation)
  • fast simulations surpassing existing solutions by 30%-60%, often matching handwritten models
  • IDE aware design

Detailed documentation, examples and precompiled binaries of all release are available on our website. To test the latest development version you can download nightly version of OpenVAF for linux or windows.

Projects

The development of OpenVAF and related tools is tightly coupled and therefore happens in a single repository. This repository currently contains the following useable projects:

OpenVAF

OpenVAF is the main project of the repository and all other tools use OpenVAF as a library in some form. OpenVAF can be build as a standalone CLI program that can compile Verilog-A files to shared objects that comply with the simulator independent OSDI interface.

OpenVAF has been tested with a preliminary NGSPICE prototype and Melange. It can already support a large array of compact models. However, due to the larger feature set (compared to VerilogAE) additional testing and verification is still required. Furthermore, some Verilog-A language features are currently not supported.

VerilogAE

Allows obtaining model equations (calculates the value of a single Variable) from Verilog-A files. VerilogAE is primarily useable from python (available on pypi) but can also be compiled as a static/shared library and called by any programming language (that supports the C ABI).

VerilogAE is used in production at SemiMod and various partners. Its stable and ready for general use.

Melange

Melange is an experimental circuit simulator that leverage OpenVAF to gain access to compact models. This allows it to easily support a large array of models without the huge effort associated with traditional simulators. The focus of Melange is primarily on automation. That means Melange focuses on providing an ergonomic and extensible API in mainstream programming languages (python and rust currently) instead of a special purpose netlist format. However, to remain compatible with existing PDKs a subset of the spectre netlist format can be parsed.

Melange is currently in early development and most features are not complete. Some mockups of planned usage can be found in melange/examples. Some working minimal examples (in rust) can be found in melange/core/test.rs.

Building OpenVAF with docker

The official docker image contains everything required for compiling OpenVAF. To build OpenVAF using the official docker containers, simply run the following commands:

git clone https://github.com/pascalkuthe/OpenVAF.git && cd OpenVAF
# On REHL distros and fedora replace docker with podman
# on all commands below. 
docker pull ghcr.io/pascalkuthe/ferris_ci_build_x86_64-unknown-linux-gnu:latest
# On Linux distros that enable SELinux linux RHEL based distros and fedora use $(pwd):/io:Z
docker run -ti -v $(pwd):/io ghcr.io/pascalkuthe/ferris_ci_build_x86_64-unknown-linux-gnu:latest

# Now you are inside the docker container
cd /io
cargo build --release
# OpenVAF will be build this can take a while
# afterwards the binary is available in target/release/openvaf
# inside the repository 

Build Instructions

OpenVAF requires rust/cargo 1.64 or newer (best installed with rustup). Furthermore, the LLVM-15 development libraries and clang-15 are required. Newer version also work but older versions of LLVM/clang are not supported. Note that its imperative that you clang version matches your LLVM version. If you want to compile VerilogAE python 3.8+ is also required.

On Debian and Ubuntu the LLVM Project provided packages can be used:

sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"

On fedora (37+) you can simply install LLVM from the default repositories:

sudo dnf install clang llvm-devel

On Linux distributions where packages for LLVM-15 are not available (like centos-7) and windows you can download the prebuild LLVM packages that are also used in our docker images. These binaries are build on centos-7 and will therefore work on any linux distribution (that is supported by rustc):

Simply download and extract these tar archives and set the LLLVM_CONFIG (see below) environment variable to point at the downloaded files: LLVM_CONFIG=<extracted directory>/bin/llvm-config.

Note: To decompress this archive you need to use the following command:

zstd -d -c --long=31 <path/to/archive.tar.zst> | tar -xf -

afterwards the decompressed files can be found in ./LLVM

Once all dependencies have been installed you can build the entire project by running:

cargo build --release

To only build OpenVAF (and ignore melange/VerilogAE) you can run:

cargo build --release --bin openvaf

By default, OpenVAF will link against the static LLVM libraries, to avoid runtime dependencies. This is great for creating portable binaries but sometimes building with shared libraries is preferable. Simply set the LLVM_LINK_SHARED environment variable during linking to use the shared system libraries. If multiple LLVM versions are installed (often the case on debian) the LLVM_CONFIG environment variable can be used to specify the path of the correct llvm-config binary. An example build invocation using shared libraries on debian is shown below:

LLVM_LINK_SHARED=1 LLVM_CONFIG="llvm-config-15" cargo build --release

OpenVAF includes many integration and unit tests inside its source code. For development cargo-nexttest is recommended to run these tests as it significantly reduces the test runtime. However, the built-in cargo test runner (requires no extra installation) can also be used. To run the testsuite simply call:

cargo test # default test runner, requires no additional installation
cargo nextest run # using cargo-nextest, much faster but must be installed first

By default, the test suite will skip slow integration tests that compile entire compact models. These can be enabled by setting the RUN_SLOW_TESTS environment variable:

RUN_SLOW_TESTS=1 cargo nextest run 

During development, you likely don't want to run full release builds as these can take a while to build. Debug builds are much faster:

cargo build # debug build
cargo run --bin opnevaf test.va # create a debug build and run it
cargo clippy # check the sourcecode for errors/warnings without building (even faster)

Acknowledgement

The architectures of the rust-analyzer and rustc have heavily inspired the design of this compiler.

Copyright

This work is free software and licensed under the GPL-3.0 license. It contains code that is derived from rustc and rust-analyzer. These projects are both licensed under the MIT license. As required a copy of the license and disclaimer can be found in copyright/LICENSE_MIT.

Many models int integration tests folder are not licensed under a GPL compatible license. All of those models contain explicit license information. They do not endup in the openvaf binary in any way and therefore do not affect the license of the entire project. Integration tests without explicit model information (either in the model files or in a dedicated LICENSE file) fall under GPLv3.0 like the rest of the repo.

openvaf's People

Contributors

bors[bot] avatar pascalkuthe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

openvaf's Issues

cargo build error on actual git master

As reported before there is no chance to build openvaf from actual github master source:

Compiling sourcegen v0.0.0 (/home/dietmar/Projects/spice/Verilog-A/OpenVAF/crates/sourcegen) error: failed to run custom build command forllvm v0.0.0 (/home/dietmar/Projects/spice/Verilog-A/OpenVAF/crates/llvm)`

Caused by:
process didn't exit successfully: /home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/llvm-24159cfe8cdbe670/build-script-build (exit status: 1)
--- stdout

cargo:rerun-if-env-changed=LLVM_CONFIG

failed to execute command: "llvm-config" "--components"
error: No such file or directory (os error 2)

warning: build failed, waiting for other jobs to finish...
`
EDIT: Sorry - this was an old git state. The error now is:

Compiling stdx v0.0.0 (/home/dietmar/Projects/spice/Verilog-A/OpenVAF/lib/stdx) error: linking withcc` failed: exit status: 1
|
= note: "cc" "-m64" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.0.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.1.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.10.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.11.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.12.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.13.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.14.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.15.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.2.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.3.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.4.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.5.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.6.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.7.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.8.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.build_script_build.0197a423-cgu.9.rcgu.o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee.1m2muwl1p74tza7t.rcgu.o" "-Wl,--as-needed" "-L" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/deps" "-L" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-a354822510b6c78e.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-fa3ecfb5450f88b6.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-198ee338df69b39c.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-9fc25c0a7dce6f29.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-d465dbef7a9af907.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-475075184bbe1c24.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-4f763e59ae2d1d84.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-981467ab45fd68f3.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-3655ead771823a28.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-7d73942097f1d46b.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-caf6c84729a78ffd.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-1457db7c997d41aa.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-646e3fa5b1f47bc7.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-8a2442e87bc3340a.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-fd4848cb46a9e78a.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-f4a392826ae45e55.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-3ddd05102d30765b.rlib" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-e7e6163debe917c0.rlib" "-Wl,--end-group" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-e2cc6b9cfff57bd1.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/home/dietmar/Projects/spice/Verilog-A/OpenVAF/target/debug/build/libc-4fa3ed94931945ee/build_script_build-4fa3ed94931945ee" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro,-znow" "-nodefaultlibs" "-fuse-ld=lld"
= note: collect2: fatal error: cannot find 'ld'
compilation terminated.

error: could not compile libc due to previous error
warning: build failed, waiting for other jobs to finish...
`

$limit function does not find analog functions

The limit function $limit is supposed to take as second argument either a string literal that specifies a simulator specific function,
or the name of an analog function defined in the code. (VAMS standard 9.17.3).

This does currently not work. Attached is an exemplary Verilog-A file.

hicumL2V2p4p0.txt

Support indirect contribute statements

When attempting to compile the juncap200rr model I hit an error:

error: unexpected token ':'; expected ';'

I can't post the exact code but the syntax of that line is something like this:

V(node) : (ddt(V(node)) == (-V(other_node)/CONSTANT + some_other_stuff);

My knowledge of VerilogA is not good enough to know if that's valid syntax but hopefully it's useful for you.

aliasparam seems not work

Using this code:

parameter real TNOM = 27.0; aliasparam TREF = TNOM;
should follow in an alternative model parametrization with TREF = 25.
But parameter TREF is still unknown.

track node abstol

Currently OSDI/OpenVAF do not expose abstol of nodes to simulators.
To ensure that proper simulation tolerances are used it is critical that the simulator uses the right tolerance for a nature.
Unresolved design issues:

  • what tolerance to use for implicit nodes where abstol is not explictly specified by the analog filter
  • allow the simulator to change voltage/current tolerance without recompiling
  • tolerance of time derivatives across timesteps vs created node
  • how should terminals be handeled? The unkowns that belong to terminals are shared across multiple instances and would require discipine checking by the simulator which is not in scope of OSDI

panic and implicite

I know implicit it is not recommended, but at least no panic for accessing port current:

    Id = I(anode);

in the attached diode example.

thread '' panicked at 'no entry found for key', openvaf/osdi/src/eval.rs:147:53
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

diode_implicit.va.txt

OpenVAF cannot compile dc source example

It seems some branch contribution are not allowed. OpenVAF cannot compile DC source example from here: https://verilogams.com/tutorials/vloga-intro.html

Here is the source file:

`include "constants.vams"
`include "disciplines.vams"

module vdd (dd);
inout dd;
electrical dd;
parameter real dc=2.5;

analog V(dd) <+ dc;
endmodule

And here is the OpenVAF output:

$ /opt/openvaf/openvaf --version
openvaf 22.12.0
$ /opt/openvaf/openvaf vdd.va
thread '<unnamed>' panicked at 'internal error: entered unreachable code: attempted to read undefined value', openvaf/mir_llvm/src/builder.rs:112:34
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)

Add support for module instantiation

Let's say I have the following components:

‘include "disciplines.vams"
module my_res (p, n);
    parameter real R=0;
    inout p, n;
    electrical p, n;
    analog
        V(p,n) <+ R * I(p,n);
endmodule

‘include "disciplines.vams"
module vsrc (p, n);
    parameter real dc=0;
    output p, n;
    electrical p, n;
    analog
        V(p,n) <+ dc;
endmodule

And I want to use them in another module. I tried this but I'm getting unexpected token error. Seems like this is not yet supported.

`include "disciplines.vams"
`include  "vsrc.va"
`include  "resistor.va"
module vdb;
    ground gnd;

    vsrc #(.dc(1)) V1(n1, gnd);
    my_res #(.R(1k)) R1(n2, n1);
    my_res #(.R(1k)) R2(n2, gnd);
endmodule

AST (Abstract Syntax Tree) from OpenVAF

Is there a way to get the AST (Abstract Syntax Tree) out of Lexer->Preprocessor -> Parser modules? I'm new in rust, can't figure out how output of 1 module is stored and passed to another.

analog initial

You should support analog initial statements. They are the preferred way of doing initialization of variable in Verilog-A.

Memory dump case

The attached example gives an memory dump:

thread 'main' panicked at 'internal error: entered unreachable code: invalid operation feq Int(0) Float(Ieee64(4604480259023595110))', openvaf/mir_opt/src/const_eval.rs:56:18 stack backtrace: 0: 0x55e1048925fd - std::backtrace_rs::backtrace::libunwind::trace::h9135f25bc195152c at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5 1: 0x55e1048925fd - std::backtrace_rs::backtrace::trace_unsynchronized::h015ee85be510df51 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5 2: 0x55e1048925fd - std::sys_common::backtrace::_print_fmt::h5fad03caa9652a2c at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:66:5 3: 0x55e1048925fd - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h2b42ca28d244e5c7 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:45:22 4: 0x55e1048b40ac - core::fmt::write::h401e827d053130ed at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/fmt/mod.rs:1198:17 5: 0x55e10488f511 - std::io::Write::write_fmt::hffec93268f5cde32 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/io/mod.rs:1672:15 6: 0x55e104893a55 - std::sys_common::backtrace::_print::h180c4c706ee1d3fb at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:48:5 7: 0x55e104893a55 - std::sys_common::backtrace::print::hd0c35d18765761c9 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:35:9 8: 0x55e104893a55 - std::panicking::default_hook::{{closure}}::h1f023310983bc730 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:295:22 9: 0x55e104893771 - std::panicking::default_hook::h188fec3334afd5be at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:314:9 10: 0x55e104894006 - std::panicking::rust_panic_with_hook::hf26e9d4f97b40096 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:698:17 11: 0x55e104893ef7 - std::panicking::begin_panic_handler::{{closure}}::hfab912107608087a at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:588:13 12: 0x55e104892af4 - std::sys_common::backtrace::__rust_end_short_backtrace::h434b685ce8d9965b at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:138:18 13: 0x55e104893c29 - rust_begin_unwind at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5 14: 0x55e1048b2633 - core::panicking::panic_fmt::ha6dc7f2ab2479463 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14 15: 0x55e101f1fbb0 - mir_opt::const_eval::eval_binary::habed9783aae3552c at /io/openvaf/mir_opt/src/const_eval.rs:56:18 Abgebrochen (Speicherabzug geschrieben)

angelov.zip

Convergence for HBT with Base Current

The convergence behavior of HBTs with current biasing at the base is problematic, likely related to the $limit function that
is missing in Verilog-A models.

A minimum netlist is printed below for replication of the issue. Questions that result:

  • is the "pnjlim" function working as expected?
  • how do commercial Verilog-A compilers handle this?
  • Or is it not pnjlim?
HICUM2v2.40 Output Test Ic=f(Vc,Ib)

IB 0 B 1u
VC C 0 1.8
VS S 0 0.0

N1 C B 0 S tj npn_full_sh

.control
pre_osdi hicumL2V2p4p0.osdi
altermod @hicumL2V2p40[flsh]=0
op
.endc

.include model-card-examples_osdi.lib

.end

where model-card-examples_osdi.lib corresponds to:

* Example parameter test set
.model npn_full_sh hicuml2va
*
*Transfer current
+ c10 = 9.074e-030
+ qp0 = 1.008e-013
+ ich = 0
+ hf0 = 40
+ hfe = 10.01
+ hfc = 20.04
+ hjei = 3.382
+ ahjei = 3
+ rhjei = 2
+ hjci = 0.2
*
*Base-Emitter diode currents
+ ibeis = 1.328e-019
+ mbei = 1.027
+ ireis = 1.5e-015
+ mrei = 2
+ ibeps = 1.26e-019
+ mbep = 1.042
+ ireps = 1.8e-015
+ mrep = 1.8
+ mcf = 1
*
*Transit time for excess recombination current at b-c barrier
+ tbhrec = 1e-010
*
*Base-Collector diode currents
+ ibcis = 4.603e-017
+ mbci = 1.15
+ ibcxs = 0
+ mbcx = 1
*
*Base-Emitter tunneling current
+ ibets = 0.02035
+ abet = 24
+ tunode = 1
*
*Base-Collector avalanche current
+ favl = 18.96
+ qavl = 5.092e-014
+ alfav = -0.0024
+ alqav = -0.0006284
+ kavl = 0.0
+ alkav = 0.0
*
*Series resistances
+ rbi0 = 4.444
+ rbx = 2.568
+ fgeo = 0.7409
+ fdqr0 = 0
+ fcrbi = 0
+ fqi = 1
+ re = 1.511
+ rcx = 2.483
*
*Substrate transistor
+ itss = 1.143e-017
+ msf = 1.056
+ iscs = 4.60106e-015
+ msc = 1.018
+ tsf = 0
*
*Intra-device substrate coupling
+ rsu = 500
+ csu = 6.4e-014
*
*Depletion Capacitances
+ cjei0 = 8.869e-015
+ vdei = 0.714
+ zei = 0.2489
+ ajei = 1.65
+ cjep0 = 2.178e-015
+ vdep = 0.8501
+ zep = 0.2632
+ ajep = 1.6
+ cjci0 = 3.58e-015
+ vdci = 0.8201
+ zci = 0.2857
+ vptci = 1.79
+ cjcx0 = 6.299e-015
+ vdcx = 0.8201
+ zcx = 0.2863
+ vptcx = 1.977
+ fbcpar = 0.3
+ fbepar = 1
+ cjs0 = 2.6e-014
+ vds = 0.9997
+ zs = 0.4295
+ vpts = 100
+ cscp0 = 1.4e-014
+ vdsp = 0
+ zsp = 0.35
+ vptsp = 4
*
*Diffusion Capacitances
+ t0 = 2.089e-013
+ dt0h = 8e-014
+ tbvl = 8.25e-014
+ tef0 = 3.271e-013
+ gtfe = 3.548
+ thcs = 5.001e-012
+ ahc = 0.05
+ fthc = 0.7
+ rci0 = 9.523
+ vlim = 0.6999
+ vces = 0.01
+ vpt = 2
+ aick = 1e-3
+ delck = 2
+ tr = 0
+ vcbar = 0.04
+ icbar = 0.01
+ acbar = 1.5
*
*Isolation Capacitances
+ cbepar = 2.609e-014
+ cbcpar = 1.64512e-014
*
*Non-quasi-static Effect
+ flnqs = 0
+ alqf = 0.166667
+ alit = 0.333333
*
*Noise
+ kf = .3e-16
+ af = .75
+ cfbe = -1
+ flcono = 0
+ kfre = 0.0
+ afre = 2.0
*
*Lateral Geometry Scaling (at high current densities)
+ latb = 0.0
+ latl = 0.0
*
*Temperature dependence
+ vgb = 0.91
+ alt0 = 0.004
+ kt0 = 6.588e-005
+ zetaci = 0.58
+ alvs = 0.001
+ alces = -0.2286
+ zetarbi = 0.3002
+ zetarbx = 0.06011
+ zetarcx = -0.02768
+ zetare = -0.9605
+ zetacx = 0
+ vge = 1.17
+ vgc = 1.17
+ vgs = 1.049
+ f1vg = -0.000102377
+ f2vg = 0.00043215
+ zetact = 5
+ zetabet = 4.892
+ alb = 0
+ dvgbe = 0
+ zetahjei = -0.5
+ zetavgbe = 0.7
*
*Self-Heating
+ flsh = 0
+ rth = 1113.4
+ cth = 6.841e-012
+ zetarth = 0
+ alrth = 0.002
*
*Compatibility with V2.1
+ flcomp = 2.3
*
*Circuit simulator specific parameters
+ tnom = 26.85
*+ dt = 0

Not valid parameter should give a warning

If a model parameter is given which is not in the model parameter table of the spice build-in models the program throws a warning on console/log or stderr:

case E_BADPARM: msg = "no such parameter on this device"; break;
Same behaviour for instance parameter.

Hisim Compilation

This issue is related to this ticket.

When compiling HisimHV 2.5, available here,
I see the following behavior.

On Linux:
The model compiles after removing a function
//* "smoothUpper" using a power function
in file HSMHV_eval_rdrift.inc.

What bugs me: OpenVAF gives a warning if this function is not removed, but still does not produce the osdi file.
If this is really a bug, it should be an error.
After removing the "smoothUpper" Macro, HISIM works for me.

On Windows:
The compilation aborts and I see:

hisimhv.o3 : error LNK2019: unresolved external symbol snprintf referenced in function cb.2 hisimhv.o4 : error LNK2001: unresolved external symbol snprintf hisimhv.osdi : fatal error LNK1120: 1 unresolved externals error: linking failed (see linker output for details) error: failed to compile hisimhv.va

Attached is a netlist.
hism_netlist.cir.txt

Compiler paniking when access the current through a port

Consider the line Itb = I(mem_plus, mem_minus); in the code below. Compiling this file causes the error below. It compiled in spectre just fine. Using Itb = I(<mem_plus>); resolves the issue. Is this a bug or is non-standard code?

thread '<unnamed>' panicked at 'no entry found for key', openvaf/osdi/src/eval.rs:147:53
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
`include "constants.vams"
`include "disciplines.vams"

module mem_ddt (mem_plus, mem_minus, gap_value, ddt_value);

    input electrical mem_plus, mem_minus, gap_value;
    output electrical ddt_value;

    parameter real      kb        = `P_K;
    parameter real      q         = `P_Q;
    parameter real      g0        = 0.25e-9  from (0:2e-9);
    parameter real      V0        = 0.25     from (0:10);
    parameter real      Vel0      = 10       from (0:20);
    parameter real      I0        = 1000e-6  from (0:1e-2);
    parameter real      beta      = 0.8      from (0:inf);
    parameter real      gamma0    = 16       from (0:inf);
    parameter real      T_crit    = 450      from (390: 460);
    parameter real      T_smth    = 500      from (400: 600);
    parameter real      Ea        = 0.6      from (0:1);
    parameter real      a0        = 0.25e-9  from (0:inf);
    parameter real      T_ini     = 273 + 25 from (0:inf);
    parameter real      F_min     = 1.4e9    from (0:3e9);
    parameter real      Rth       = 2.1e3    from (0:inf);
    parameter real      tox       = 12e-9    from (0:100e-9);
    parameter real      time_step = 1e-9     from (1e-15: 1);

    real            Vtb, Itb;
    real            T_cur;
    real            gap_ddt;
    real            gamma;
    real            gamma_ini;
    real            gap;

    parameter real      pulse_width = 20n;

    analog begin
        $bound_step(time_step);

        Vtb = V(mem_plus, mem_minus);
        Itb = I(mem_plus, mem_minus);
        gap = V(gap_value);

        T_cur = T_ini + abs( Vtb * Itb * Rth);
        gamma_ini = gamma0;

        if(Vtb < 0) begin
            gamma_ini = 16;
        end

        gamma = gamma_ini - beta * pow((( gap )/1e-9), 3);

        if ((gamma * abs( Vtb )/ tox) < F_min) begin
            gamma = 0;
        end

        gap_ddt = - Vel0 * exp(- q * Ea / kb / T_cur) * sinh(gamma * a0 / tox * q * Vtb / kb / T_cur);

        V(ddt_value) <+ gap_ddt;
    end
endmodule

Support multiplicity attribute

OpenVAF currently does not recognize the multiplicity attribute. This attribute has no impact on the actual simulation.
It is only used to scale operating variables by $mfactor when reported to the simulator.
Relevent excerpt from the Verilog-A LRM:

The multiplicity attribute is used to describe how the value of a parameter or variable should be
scaled for reporting. The attribute must be assigned one of the following string values: "multiply",
"divide", or "none". If the attribute is specified with the value "multiply", the value for the
associated parameter or variable will be multiplied by the value of $mfactor for the instance in
any report of operating-point values. If the attribute is specified with the value "divide", the value
for the associated parameter or variable will be divided by the value of $mfactor for the instance
in any report of operating-point values. If the multiplicity attribute is not specified, or specified
with the value "none", then no scaling will be performed. Note that this scaling only applies to oper-
ating-point value reports; it does not affect the automatic scaling detailed in 6.3.6.

This should be easy to implement however I assigned low priority as it does not affect simulation results and is only sparsely used in real-world models.

Verilog-A idt operator supported?

Trying a simple simulation with OpenVAF and ngspice, I noticed that the result of the integration operator never changes, is it not supported or am I doing something wrong?
The integrated value changes when simulating with Cadence Spectre, but remains stuck at 0 in OpenVAF.

Verilog code:

`include "disciplines.vams"

module testidt(outreal, gnd);
output outreal;
inout gnd;
electrical outreal;
electrical gnd;
real phase;

analog begin
        phase = idt (1, 0);
        V(outreal) <+ phase;
        $strobe("%f %f\n", $abstime, phase);
end
endmodule

ngspice circuit:

* OSDI test
.control
pre_osdi testidt.osdi
.endcontrol
.model mytest testidt

N1 int 0 mytest
.tran 1s 10s
.PRINT TRAN V(int)

thread main panicked

The attached simple switch.va got panick with v 22.12.0.

dietmar@modsys:~/Projects$ RUST_BACKTRACE=1 openvaf -I .. switch.va thread 'main' panicked at 'the parser seems stuck', openvaf/parser/src/parser.rs:51:9 stack backtrace: 0: rust_begin_unwind at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5 1: core::panicking::panic_fmt at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14 2: parser::parser::Parser::nth at /io/openvaf/parser/src/parser.rs:51:9 3: parser::parser::Parser::current at /io/openvaf/parser/src/parser.rs:42:9 4: parser::parser::Parser::at_ts at /io/openvaf/parser/src/parser.rs:80:24 5: parser::grammar::stmts::event_stmt at /io/openvaf/parser/src/grammar/stmts.rs:68:16 6: parser::grammar::stmts::stmt at /io/openvaf/parser/src/grammar/stmts.rs:23:18 note: Some details are omitted, run with RUST_BACKTRACE=fullfor a verbose backtrace. Abgebrochen (Speicherabzug geschrieben)
switch.va.txt

bus definition

When attempting bus definitions like this:

input [0:4] in ;

I get an error like this:

  |
6 | input [0:4] in ;
  |       ^ expected identifier

How should I define a bus to be recognized by openvaf?

Note: Single signals do not generate this error.

Support hidden state variables

I am testing a memristor model from here called "Joglekar Resistance Switch Model in Verilog-A". After some minor modifications, it was able to compile with openvaf. The result produced is not what I was expecting.

This is the current I(V1) plot from ngspice.

image

Of course, there's the possibility that I introduced a mistake when I modified the file. So, I simulated the same verilog-a model in spectre. The plot of the current I(V1) is shown below.

image

The modified verilog-a file is given below.

`include "disciplines.vams"

`define X_BORDER_BUMP 10e-18

module joglekar_memristor (p,n);

    inout p,n;
    electrical p,n;

    parameter real Roff=16000 from (0:inf);
    parameter real Ron=100 from (0:inf);
    parameter real Rinit=11000 from (0:inf);
    parameter real D=10n from (0:inf);
    parameter real uv=10e-15 from (0:inf);
    parameter real p_coeff=1.0 from (0:inf);

    // local variables that should persist over time steps
    real w_last;
    real time_last;

    // local variables that hold temporary values
    real G;
    real window_function;
    real w;
    real dw;
    real R;
    real direction;
    real mem_current;
    real abstime;
    real time_delta;


    analog begin

    @(initial_step)
    begin
        w_last = ((Roff - Rinit) / (Roff - Ron)) * D;
        time_last = 0;
    end

    // calculate conductance
    G = 1 / (Ron * w_last / D + Roff * (1 - w_last / D));
    mem_current = G * V(p,n);


    direction = 0;
    if (mem_current > 0) begin
        if(w_last<=0) begin
            direction=1;
        end
    end
    else
    begin
        if(w_last>=D) begin
            direction=-1;
        end
    end

    abstime = $abstime;
    time_delta = abstime - time_last;
    window_function = (1.0 - (pow(2 * w_last / D - 1, 2 * p_coeff)));
    dw = uv * Ron / D * mem_current * window_function * time_delta;
    w = w_last + dw + direction * `X_BORDER_BUMP;

    if(w >= D) begin
        w = D;
    end

    if(w <= 0) begin
        w = 0;
    end

    // calculate conductance
    G = 1 / (Ron * w / D + Roff * (1 - w / D));

    // set the mem_current
    I(p,n) <+ -1.0*G*V(p,n);

    // persist variables
    w_last = w;
    time_last = abstime;

end
endmodule

The ngspice netlist is given below:

.title Verilog-A memristor test

.model my_memristor joglekar_memristor

V1 1 0 SIN(0V 1.2V 1Hz)
NX1 1 0 my_memristor

.control
*set filetype=ascii
pre_osdi ./joglekar_memristor.osdi
tran 1ms 1s
plot I(V1) retraceplot
*write res.txt
.endc
 
.end

Here's the plot data from spectre:

time (s),/V0/PLUS (A)
0.000,0.000
1.000E-3,685.4E-9
3.000E-3,2.056E-6
7.000E-3,4.798E-6
15.00E-3,10.28E-6
31.00E-3,21.23E-6
51.00E-3,34.86E-6
71.00E-3,48.34E-6
91.00E-3,61.61E-6
111.0E-3,74.61E-6
131.0E-3,87.28E-6
151.0E-3,99.58E-6
171.0E-3,111.5E-6
191.0E-3,122.9E-6
211.0E-3,133.7E-6
231.0E-3,144.0E-6
251.0E-3,153.6E-6
271.0E-3,162.4E-6
291.0E-3,170.0E-6
311.0E-3,176.1E-6
331.0E-3,180.1E-6
351.0E-3,181.2E-6
371.0E-3,178.4E-6
391.0E-3,170.3E-6
411.0E-3,155.4E-6
431.0E-3,132.6E-6
451.0E-3,101.4E-6
471.0E-3,62.97E-6
491.0E-3,19.88E-6
511.0E-3,-23.93E-6
531.0E-3,-64.43E-6
551.0E-3,-98.59E-6
571.0E-3,-125.0E-6
591.0E-3,-143.6E-6
611.0E-3,-155.5E-6
631.0E-3,-161.9E-6
651.0E-3,-164.1E-6
671.0E-3,-163.1E-6
691.0E-3,-159.9E-6
711.0E-3,-154.9E-6
731.0E-3,-148.6E-6
751.0E-3,-141.3E-6
771.0E-3,-133.1E-6
791.0E-3,-124.2E-6
811.0E-3,-114.6E-6
831.0E-3,-104.3E-6
851.0E-3,-93.56E-6
871.0E-3,-82.23E-6
891.0E-3,-70.41E-6
911.0E-3,-58.16E-6
931.0E-3,-45.53E-6
951.0E-3,-32.58E-6
971.0E-3,-19.39E-6
985.5E-3,-9.719E-6
1.000,-26.17E-21

Here's the plot data from ngspice:

Title: Verilog-A memristor test
Date: Wed May  3 00:44:48  2023
Plotname: Transient Analysis
Flags: real
No. Variables: 3
No. Points: 108
Variables:
	0	time	time
	1	v(1)	voltage
	2	i(v1)	current
Values:
 0	0.000000000000000e+00
	0.000000000000000e+00
	0.000000000000000e+00

 1	1.000000000000000e-04
	7.539821872515087e-04
	6.854383520468261e-08

 2	2.000000000000000e-04
	1.507964076842791e-03
	1.370876784855389e-07

 3	4.000000000000000e-04
	3.015925772404472e-03
	2.741753513080024e-07

 4	8.000000000000000e-04
	6.031832494582635e-03
	5.483506573092273e-07

 5	1.600000000000000e-03
	1.206351258807679e-02
	1.096700952094711e-06

 6	3.200000000000000e-03
	2.412580599054910e-02
	2.193399001774594e-06

 7	6.400000000000000e-03
	4.824185923554385e-02
	4.386774713020286e-06

 8	1.280000000000000e-02
	9.640572016007308e-02
	8.773360821304827e-06

 9	2.280000000000000e-02
	1.713205573769387e-01
	1.563053094602801e-05

 10	3.280000000000000e-02
	2.455592706227552e-01
	2.251014790110941e-05

 11	4.280000000000000e-02
	3.188288736127832e-01
	2.941502580883767e-05

 12	5.280000000000001e-02
	3.908402046977186e-01
	3.635163964851341e-05

 13	6.280000000000001e-02
	4.613090680526169e-01
	4.332542477742161e-05

 14	7.280000000000000e-02
	5.299573552679777e-01
	5.034046306112031e-05

 15	8.280000000000000e-02
	5.965141429165811e-01
	5.739912351675138e-05

 16	9.279999999999999e-02
	6.607167617644818e-01
	6.450164843435150e-05

 17	1.028000000000000e-01
	7.223118334064741e-01
	7.164567625347727e-05

 18	1.128000000000000e-01
	7.810562702348983e-01
	7.882569333347123e-05

 19	1.228000000000000e-01
	8.367182347953729e-01
	8.603240846423267e-05

 20	1.328000000000000e-01
	8.890780547433106e-01
	9.325204690766777e-05

 21	1.428000000000000e-01
	9.379290897903031e-01
	1.004655654207504e-04

 22	1.528000000000000e-01
	9.830785472189348e-01
	1.076477966613794e-04

 23	1.628000000000000e-01
	1.024348242747560e+00
	1.147665412491293e-04

 24	1.728000000000000e-01
	1.061575303742258e+00
	1.217816391646492e-04

 25	1.828000000000000e-01
	1.094612812000709e+00
	1.286440696026849e-04

 26	1.928000000000000e-01
	1.123330383571218e+00
	1.352951499700802e-04

 27	2.028000000000000e-01
	1.147614683318607e+00
	1.416659299029734e-04

 28	2.128000000000000e-01
	1.167369872206216e+00
	1.476769033540473e-04

 29	2.228000000000001e-01
	1.182517985528790e+00
	1.532381878133768e-04

 30	2.328000000000001e-01
	1.192999240603561e+00
	1.582503394432688e-04

 31	2.428000000000001e-01
	1.198772272705179e+00
	1.626059790290636e-04

 32	2.528000000000001e-01
	1.199814298313386e+00
	1.661923870449562e-04

 33	2.628000000000001e-01
	1.196121205029163e+00
	1.688951770734989e-04

 34	2.728000000000001e-01
	1.187707567804489e+00
	1.706030673754343e-04

 35	2.828000000000001e-01
	1.174606591421664e+00
	1.712136380789897e-04

 36	2.928000000000001e-01
	1.156869979449205e+00
	1.706397934031704e-04

 37	3.028000000000001e-01
	1.134567730191479e+00
	1.688164648653120e-04

 38	3.128000000000001e-01
	1.107787860437379e+00
	1.657069266811473e-04

 39	3.228000000000001e-01
	1.076636058098265e+00
	1.613079921509521e-04

 40	3.328000000000002e-01
	1.041235265106064e+00
	1.558538463481697e-04

 41	3.428000000000002e-01
	1.001725192217634e+00
	1.490689431351353e-04

 42	3.528000000000002e-01
	9.582617676402292e-01
	1.412085271979401e-04

 43	3.628000000000002e-01
	9.110165216541070e-01
	1.324084370648376e-04

 44	3.728000000000002e-01
	8.601759096608749e-01
	1.228289398354197e-04

 45	3.828000000000002e-01
	8.059405763292041e-01
	1.126465055841991e-04

 46	3.928000000000002e-01
	7.485245637419874e-01
	1.020448449365426e-04

 47	4.028000000000002e-01
	6.881544666700257e-01
	9.120611439395653e-05

 48	4.128000000000002e-01
	6.250685383059880e-01
	8.030308659462463e-05

 49	4.228000000000002e-01
	5.595157499879083e-01
	6.949286607155171e-05

 50	4.328000000000002e-01
	4.917548086230577e-01
	5.891246217722088e-05

 51	4.428000000000002e-01
	4.220531356899738e-01
	4.867626756043444e-05

 52	4.528000000000003e-01
	3.506858118480581e-01
	3.887527692099191e-05

 53	4.628000000000003e-01
	2.779344913198859e-01
	2.957773972589799e-05

 54	4.728000000000003e-01
	2.040862903306650e-01
	2.083087474433391e-05

 55	4.828000000000003e-01
	1.294326539916660e-01
	1.266327160233257e-05

 56	4.928000000000003e-01
	5.426820609951687e-02
	5.087645824140221e-06

 57	5.028000000000002e-01
	-2.111041360932151e-02
	-1.896321000411765e-06

 58	5.128000000000003e-01
	-9.640572016007502e-02
	-8.299251863822532e-06

 59	5.228000000000003e-01
	-1.713205573769408e-01
	-1.413958364552502e-05

 60	5.328000000000003e-01
	-2.455592706227573e-01
	-1.944138564465301e-05

 61	5.428000000000003e-01
	-3.188288736127849e-01
	-2.423251393653644e-05

 62	5.528000000000003e-01
	-3.908402046977204e-01
	-2.854309720159027e-05

 63	5.628000000000003e-01
	-4.613090680526187e-01
	-3.240432997216986e-05

 64	5.728000000000003e-01
	-5.299573552679795e-01
	-3.584753839242560e-05

 65	5.828000000000003e-01
	-5.965141429165829e-01
	-3.890347918105611e-05

 66	5.928000000000003e-01
	-6.607167617644838e-01
	-4.160183242260780e-05

 67	6.028000000000003e-01
	-7.223118334064761e-01
	-4.514448958790476e-05

 68	6.128000000000003e-01
	-7.810562702349003e-01
	-4.881601688968127e-05

 69	6.228000000000004e-01
	-8.367182347953749e-01
	-5.229488967471093e-05

 70	6.328000000000004e-01
	-8.890780547433124e-01
	-5.556737842145702e-05

 71	6.428000000000004e-01
	-9.379290897903048e-01
	-5.862056811189405e-05

 72	6.528000000000004e-01
	-9.830785472189362e-01
	-6.144240920118352e-05

 73	6.628000000000004e-01
	-1.024348242747562e+00
	-6.402176517172260e-05

 74	6.728000000000004e-01
	-1.061575303742259e+00
	-6.634845648389121e-05

 75	6.828000000000004e-01
	-1.094612812000710e+00
	-6.841330075004437e-05

 76	6.928000000000004e-01
	-1.123330383571219e+00
	-7.020814897320118e-05

 77	7.028000000000004e-01
	-1.147614683318608e+00
	-7.172591770741303e-05

 78	7.128000000000004e-01
	-1.167369872206216e+00
	-7.296061701288850e-05

 79	7.228000000000004e-01
	-1.182517985528790e+00
	-7.390737409554940e-05

 80	7.328000000000005e-01
	-1.192999240603561e+00
	-7.456245253772260e-05

 81	7.428000000000005e-01
	-1.198772272705179e+00
	-7.492326704407370e-05

 82	7.528000000000005e-01
	-1.199814298313386e+00
	-7.498839364458665e-05

 83	7.628000000000005e-01
	-1.196121205029163e+00
	-7.475757531432270e-05

 84	7.728000000000005e-01
	-1.187707567804489e+00
	-7.423172298778055e-05

 85	7.828000000000005e-01
	-1.174606591421664e+00
	-7.341291196385398e-05

 86	7.928000000000005e-01
	-1.156869979449204e+00
	-7.230437371557525e-05

 87	8.028000000000005e-01
	-1.134567730191478e+00
	-7.091048313696740e-05

 88	8.128000000000005e-01
	-1.107787860437378e+00
	-6.923674127733610e-05

 89	8.228000000000005e-01
	-1.076636058098263e+00
	-6.728975363114147e-05

 90	8.328000000000005e-01
	-1.041235265106063e+00
	-6.507720406912893e-05

 91	8.428000000000005e-01
	-1.001725192217633e+00
	-6.260782451360204e-05

 92	8.528000000000006e-01
	-9.582617676402274e-01
	-5.989136047751421e-05

 93	8.628000000000006e-01
	-9.110165216541053e-01
	-5.693853260338158e-05

 94	8.728000000000006e-01
	-8.601759096608728e-01
	-5.376099435380455e-05

 95	8.828000000000006e-01
	-8.059405763292019e-01
	-5.037128602057512e-05

 96	8.928000000000006e-01
	-7.485245637419854e-01
	-4.678278523387409e-05

 97	9.028000000000006e-01
	-6.881544666700231e-01
	-4.300965416687644e-05

 98	9.128000000000006e-01
	-6.250685383059859e-01
	-3.906678364412411e-05

 99	9.228000000000006e-01
	-5.595157499879055e-01
	-3.496973437424410e-05

 100	9.328000000000006e-01
	-4.917548086230554e-01
	-3.073467553894096e-05

 101	9.428000000000006e-01
	-4.220531356899709e-01
	-2.644496734468493e-05

 102	9.528000000000006e-01
	-3.506858118480557e-01
	-2.312509760211469e-05

 103	9.628000000000007e-01
	-2.779344913198829e-01
	-1.938801116901117e-05

 104	9.728000000000007e-01
	-2.040862903306625e-01
	-1.514600586823299e-05

 105	9.828000000000007e-01
	-1.294326539916630e-01
	-1.028423975906868e-05

 106	9.928000000000007e-01
	-5.426820609951436e-02
	-4.649617059142608e-06

 107	1.000000000000000e+00
	-2.939152317953648e-16
	-2.671956652685134e-20

I did these tests on: openvaf 23.2.0 and ngspice 40

OSDI/OpenVAF: Verilog-A compact models in ngspice

Discussed in #22

Originally posted by Marvelousmay January 11, 2023
I used the precompiled standalone executable of Openvaf. Here I tried compiling a comparator model using Verilog-ams language, but I failed, it reported an error like this:

# openvaf comparator.va
thread '<unnamed>' panicked at 'internal error: entered unreachable code: attempted to read undefined value', openvaf/mir_llvm/src/builder.rs:112:34
note: run with environment variable to display a backtrace

My comparator model is as follows:

`include "disciplines.vams"
`include "constants.vams"

module comparator (sigin, sigref, sigout);
input sigin,sigref;
output sigout;
electrical sigin, sigref, sigout;
parameter real sigout_high = 10;
parameter real sigout_low = -10;
parameter real sigin_offset = 0;
parameter real comp_slope = 1000;

analog begin

@( initial_step) begin
    if (sigout_high <= sigout_low) begin
    $display("Range specification error. sigout_high = (%E) less than sigout_low = (%E).\n",sigout_high,sigout_low);
    $finish;
    end
end

V(sigout) <+ 0.5 * (sigout_high - sigout_low)* tanh(comp_slope*(V(sigin, sigref) - sigin_offset))+(sigout_high + sigout_low)/2;
end
endmodule

I tried another simple model and found that the problem appeared here, and that is that I can only express V like this:
I(p,n) <+ idt(V(p,n))/L;
Instead of using:
V(p,n) <+ L*ddt(I(p,n));
So when I want to express a V relationship for example:
V(n2,n1) <+ gain * sin(2 * `M_PI * freq * $abstime);
How can I modify it?
Looking forward to a reply.

Math Functions

Are there any limitations on the types of inputs the math functions can take? (sqrt, exp, ln)
when creating a component which has the following definition:
y <+ x;
The va code compiles and the spice simulation produces a reasonable output.
When taking the square root of this value,
y <+ sqrt(x);
the va code compiles and the spice simulation produces -NaN as the output.

Alternatively, is there a specific library which must be included to use these? (Side note: cos and sin appear to work well)

Expose a `param_given` function in OSDI

This allows simulator to determine whether a parameter was manually supplied or set to a default value withku duplicating tracking. This makes freeing string parameters easier for instance. For prior discussion see #74

Weird Compilation Behavior

See attached Ngspice Circuit that uses the attached hicum Verilog-A Code.

If we run the circuit with:

Vbiei = $limit(V(br_biei), "pnjlim", VT, 5.0);

in line 1303 Ngspice does not work and says: Error: no such device or model name hicuml2v2p40
If I change the line to

Vbiei = $limit(V(br_biei), "pnjlim", VT, 1.0);

Ngspice does not throw this error.

issue_compile.zip

Module attributes

It seems module attributes are accepted by openVAF:
(* ngspiceModelGroup="semi", ngspiceLevelNumber="1", ngspiceDeviceName="nigbt", ngspiceTypeVariable="N" *) module nigbt (a, g, c);
But the question is, where they are will landing and how can I use them in simulator?

Request for implementing $discontinuity

Hi,

Please support $disconitnuity. Much like $bound_step it should be simple to implement but would make it possible to correctly define signal sources with discontinuous derivatives in OpenVAF compiled models.

During instance evaluation all reached $discontinuity(n) statements should be recorded. The argument of $discontinuity should be an expression that evaluates to a non-negative integer. It can depend only on parameters and constants, not on quantities like voltages and currents computed by the simulator.

The instance data structure should have two additional information available:

  1. was there a $disconitunity reached during last instance evaluation (true/false)?
  2. what was the smallest value of the argument passed to reached $discontinuity statements during last instance evaluation.

Thanks,
Arpad

$realfreq feature request

Never understood why $abstime for time domain is available and $realfreq in frequency domain not in LRM.
Not important, but in times of growing new noise models it would helpful.

Noise contribution distorbs DC model

In fact the noise model in the attached code is more as questionable. We have a parallel current and voltage contribution to same branch:

`// shot noise

    I(bii,biii) <+ V(bii,biii)*1e5;

    V(bii,biii) <+ white_noise(abs(2*(nf*`KBOLTZ*TjK)*(nf*`KBOLTZ*TjK)/(`QELECTRON*Ic1)) , "Vbe");

`
But the issue is, that the noise contribution affected the dc simulation result very strong, so the model is not usable. Removing the noise part dc results are reasonable.

Is that behaviour inline with LRM and Verilog-A? Expectation is that the white_noise contribution affect only ac and noise simulations base on small-signal model. Should a warning issued if different contribution types go on same branch?

fbhhbt-2.3.zip

Question of "Linker not found".

Hi, I'm using OpenVAF to handle the BSIM-CMG, but when I using OpenVAF 23_2_0 in Windows, there are two errors:

error: linker not found: program not found
error: failed to compile bsimcmg.va

Docs of OpenVAF refered that "On Windows the MSVC build tools must be downloaded and installed from the microsoft website." But after I installed the BuildTools, the errors are still here.
But when I using the OpenVAF 22, the ".va" file can be compiled. I wander if there are anything I need to install, thanks.

the parser seems stuck

I have many Verilog-A models that currently cause OpenVA to crash. Perhaps this is because they are using features of the language you do not yet support. I largely write functional models rather than device models. Anyway, if you want to try it, here is one such model:

`include "disciplines.vams"

module inv (out, in);
output out;
input in;
electrical out, in;
parameter real vdd=1.8;
parameter real tt=1u;

analog begin
    @(cross(V(in) - vdd/2))
        ;
    V(out) <+ vdd*transition(V(in)<vdd/2, 0, tt);
end
endmodule

The problem seems to be with the event statement. If I comment it out I do get an error message indicating that transition is not yet supported.

Do you want my other examples? If so, how should I get them to you?

Recording output variables during transient simulation

Using ngspice-39 I am trying to save OPVARs during a transient simulation. When saving a vector of the right dimensions (same as simulation steps) is created but all its values are 0 except the first one.

Is it possible to save the value of OPVARs during all the steps of a transient simulation?

port directions should be optional

Port directions are often not specified for Verilog-A models because the simulator does not use the port direction. It is primarily needed in Verilog-AMS when inserting connect modules. By insisting on port directions you are making OpenVAF incompatible with standard-complient models and forcing user to add extra clutter to their models.

paramset support

paramsets were added to Verilog-A in version 2.4 for two reasons:

  1. to provide a Verilog-A/MS native way to specify the information normally provided by the SPICE .model cards (this was considered the last barrier to the enabling of a pure Verilog netlist for circuit simulators, which would allow us to finally leave behind the long painful era of vendor specific netlists).
  2. to provide optimizing compilers a way of dramatically increasing the efficiency of simulation by flooding the code with constants (the model parameters), that would allow substantial opportunities for expression pre-evaluation and code pruning.

The speed up from paramsets was envisioned to result from combining the code and the paramset before compiling. So rather than one compiled mosfet model in a simulation, there one be one compiled for each .model card in the PDK. This allows for pre-evaluation of many expressions and elimination of many conditionals. It also eliminates the distinction between model and instance parameters, resulting in substantially smaller instance data structures, which improves cache performance.

paramsets represent a significant change to the concept of the SPICE model card that dramatically affects the architecture of the compiler and the simulator, but promises substantial increases in performance. It should be built into the compiler from the start. The commercial model compilers were initially developed before paramsets were defined and missed out on the opportunity provided by paramsets.

Do you have any intention of supporting paramsets?

default parameter types

Verilog does not require explicit specification of parameter types. If not given, the type is taken from the default value, which is required. Thus:

    parameter dir=+1;
    parameter thresh=1.0;

declares two parameters, the first is an integer (because +1 is an integer) and thresh is real (because 1.0 is a real).

These declarations are rejected by OpenVAF because they are missing the explicitly specified type (integer, real, or string).

support ac_stim

OpenVAF does currently not support ac_stim because it can not be realised with the simulation independent resistive/reactive components. Another function needs to be introduced to OSDI that loads complex small signal stimulations into a seperate vector

link error on win10

I made first trial under windows 10 64bit. Placed the openvaf.exe in my PATH:

c:\msys64\home\dwarning\spice\Verilog-A\VA-Models\code\vbic\vacode>openvaf.exe --version
openvaf 23.2.0

Compiling the model I got:

c:\msys64\home\dwarning\spice\Verilog-A\VA-Models\code\vbic\vacode>openvaf.exe vbic_1p3.va
Non-UTF-8 output: Bibliothek "vbic_1p3.lib" und Objekt "vbic_1p3.exp" werden erstellt.\r\nvbic_1p3.o3 : error LNK2019: Verweis auf nicht aufgel\x94stes externes Symbol "snprintf" in Funktion "cb.2".\r\nvbic_1p3.osdi : fatal error LNK1120: 1 nicht aufgel\x94ste Externe\r\n
error: linking failed (see linker output for details)
error: failed to compile vbic_1p3.va

Seems a C stdlib is not into the executable.

EDIT: Just seen in Changelog: Something has changed with ms runtime library. Have I to install something additional?
The old binary 22.12 works fine.

Missing ground and thermal syntax elements

Problems with openvaf version 22.12.0:

ground nodes not accepted:
//internal nodes electrical gnd; thermal ti; ground gnd;

Access function for thermal nodes seems not implemented:
Texi = Temp(ti);

Example case:

fbhhbt.zip

Using parameter "--target_cpu" results in error

Using the command line parameter --target_cpu, I get the error message shown below.
I have also attached the resulting log file. Version is the nightly build download from July 4th, 2023

If I omit the --target_cpu parameter, it works just fine (the resulting osdi library also works as expected in ngspice-40).
The problem also happens for version 23.2.0. The VerilogA file is the Berkeley BSIM-CMG-110 implementation.

I'd like to be able to build 'generic' osdi libraries that I can roll out on our servers while building the osdi library on my more recent local CPU.

$ ./openvaf -V
openvaf 23.5.0

$ ./openvaf --target_cpu generic -o bsimcmg.osdi bsimcmg.va  
OpenVAF encountered a problem and has crashed!

A log file has been generated at "/tmp/openvaf-crash-1688476020.log".

$ cat /tmp/openvaf-crash-1688476020.log

OpenVAF 23.5.0
Panic occurred in file '/root/project/vendor/clap_builder/src/parser/error.rs' at line 32
Mismatch between definition and access of `target_cpu`. Could not downcast to TypeId { t: 13307641874416792075 }, need to downcast to TypeId { t: 9611275717051495212 }
...

$ ./openvaf -o bsimcmg.osdi bsimcmg.va  
Finished building bsimcmg.va in 2.66s

openvaf-crash-1688476020.log

String parameters in OpenVAF

Does OpenVaf support string parameters? I tried compiling a .va file containing the following line

(desc= "Dummy", type="instance", units = "none") parameter string dummy = "abc";

OpenVAF crashed (says it panicked because it entered unreachable code).

On the OSDI side, calling access() for a string parameter returns a void* pointer. How should I interpret this pointer? Should I cast it to char**?

Suppose I do this for a string parameter:

char** ptr = (char**)(osdiDescriptor->access(...));
free(*ptr);
ptr = (char)malloc(...);
strcpy(*ptr, "new string");

Is this OK in the spirit of OSDI and OpenVAF?

Obsolete warning

This is not a really issue: I think for gmin it is correct not to have a static, fixed value which is set one times and then never changed. The problem has two sides:

  1. All other measures, like "shrink" in this case, are static and should never change in simulation. So they are not problematic.
  2. The true problem with "gmin" is not the define of a macro, it is the place where it is used.

warning[L015]: call to $simparam in a constant is evaluted before the simulation
--> /home/dietmar/Projects/spice/Verilog-A/VA-Models/code/r3_cmc/vacode/r3_cmc_macros.include:175:20
|
175 | `define SIMPARSHRI $simparam("shrink",0.0)
| ^^^^^^^^^^^^^^^^^^^^^^^ call to $simparam in a constant
|
= help: the value of paramaeters like "gmin' or "sourceScaleFactor" may vary between iterations
= variant_const_simparam is set to warn by default

ddt() outside of contribution statement

Is the application of the ddt() operator allowed outside of contribution statements?
E.g.:
taur = (3qb)/(cbcjddt(vds));

openvaf is not complaining to this. LRM don't forbid this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.