don't vendor llvm-sys, depend on it

[Kreijstal]

//! This is a vendored version of [llvm-sys](https://gitlab.com/taricorp/llvm-sys.rs)
//! adjusted to fit the needs of this project. Furthermore some improvements to llvm made in rustc
//! have been copied here.

Now your program will always be outdated unless you manually rebase the llvm part.

[dwarning]

Sorry, can you explain elaborately this finding. When it is happen, which OS you are using? Can you give some hints for the rebase action for git novices too. Thanks.

[Kreijstal]

Sorry, can you explain elaborately this finding. When it is happen, which OS you are using? Can you give some hints for the rebase action for git novices too. Thanks.

idk if you are asking for code but look at #143 143

[Lang0722]

Sorry, can you explain elaborately this finding. When it is happen, which OS you are using? Can you give some hints for the rebase action for git novices too. Thanks.

idk if you are asking for code but look at #143 143

Thanks for your work, but could you please explain more than TLDR about your commits?

[Kreijstal]

Sorry, can you explain elaborately this finding. When it is happen, which OS you are using? Can you give some hints for the rebase action for git novices too. Thanks.

idk if you are asking for code but look at #143 143

Thanks for your work, but could you please explain more than TLDR about your commits?

im trying to depend on llvm_sys rather than on llvm itself trusting hopefully the bindings will update automatically

[dvc94ch]

seems like a reasonable engineering decision. I built your PR against the arch linux distributed llvm. would be nice to see some more coordination on openvaf, it seems there are at least 3 forks with interesting patches.

@arpadbuermen if you are going to maintain openvaf reloaded, it might make sense to create a new repo instead of a fork so that issues can be opened. updating llvm seems like some needed maintenance.

does anyone know how semimod is doing their parameter extraction now? seems like openvaf/verilogae/dmt were the core tools in their workflow. presumably they just work well enough for them now?

[arpadbuermen]

Now that you suggested it I will consider it. I have two reservations

• if I do that I lose all the stars, so everybody pinky swear you will star the new repo :),
• can anybody explain if it will make harder to cherry-pick commits from Geoffrey and Dietmar? I am a novice to git...

Currently I am busy with implementing harmonic balance in VACASK (the OpenVAF part and half of the solver is done) and I have a paper to revise. After that I will probably do it.

Disclaimer: I am not familiar with all the internals of OpenVAF. Don't expect too much in the realm of bug fixing :)

[dvc94ch]

if I do that I lose all the stars, so everybody pinky swear you will star the new repo :)

I can star it... :)

can anybody explain if it will make harder to cherry-pick commits from Geoffrey and Dietmar? I am a novice to git...

no, it doesn't make a difference

I am busy with implementing harmonic balance in VACASK

sounds cool, had to google what harmonic balance is

I'm not an expert in any of these topics. My current weekend project is trying to build some transistor circuits using laser induced graphene electrodes on polyimide film and an inkjet deposited PEDOT:PSS layer. So I'm at the stage of trying to produce and figure out how to test if what was produced is actually a transistor, not extracting dozens of parameters from a sophisticated model.

[tcaduser]

Currently I am busy with implementing harmonic balance in VACASK (the OpenVAF part and half of the solver is done) and I have a paper to revise. After that I will probably do it.

I've implemented HB multiple times, including (HB noise) in my career, so please let me know if you would like any help on this item.

Here is a simple implementation I've done for periodic steady state: https://github.com/devsim/pyhb

[arpadbuermen]

@tcaduser Great. I will let you know when I hit the wall. Otherwise some pointers regarding PAC, PXF, PNOISE, QPAC, QPXF, QPNOISE analyses would be very helpful. I hear all you need is the conversion matrix which is a byproduct of HB. But don't know exactly how to perform them and what they mean. Cadence docs are good, but not good enough.

[tcaduser]

great, I just changed the visibility of the project to public, in case the link didn't before. Please let me know if there is a preferred place for this discussion. The conversion matrix has almost twice the dimension of the steady state matrix to handle small-signal perturbations at each sideband of the large signal carrier.

Here are some thesis from Stanford from the TCAD perspective of HB. Troyanovsky adapted a lot of their work from how simulations were done by HP/Agilent/Keysight ADS: http://www-tcad.stanford.edu/tcad/pubs/theses/boris_thesis.pdf

Continuation of work with noise simulations. http://www-tcad.stanford.edu/~fmr/research/docs/thesis5p0.pdf

My thesis concerning more noise simulation. https://ufdc.ufl.edu/UFE1001178/00001/pdf

Note all of this work is derived from how it is done using circuit simulation.

[arpadbuermen]

We can move to my mail to not bother the masses with our petty discussions. :) See my profile.

[arpadbuermen]

@dvc94ch if that is not a joke (communication via chat makes everybody somewhat Asperger), then you are doing some really cool stuff.

[dvc94ch]

doesn't a joke have to be funny? there is recently published research from this year showing it's a viable path... happy to talk about it more somewhere else, not sure how to find other people interested in this weird topic...

[Kreijstal]

@arpadbuermen Can you enable issues/discussion on your fork? Unless you don't want that for some reason?

[Kreijstal]

seems like a reasonable engineering decision. I built your PR against the arch linux distributed llvm. would be nice to see some more coordination on openvaf, it seems there are at least 3 forks with interesting patches.

@arpadbuermen if you are going to maintain openvaf reloaded, it might make sense to create a new repo instead of a fork so that issues can be opened. updating llvm seems like some needed maintenance.

does anyone know how semimod is doing their parameter extraction now? seems like openvaf/verilogae/dmt were the core tools in their workflow. presumably they just work well enough for them now?

which flags did you use to build it?

[dvc94ch]

cargo build --release

git diff .
diff --git a/openvaf/openvaf-driver/Cargo.toml b/openvaf/openvaf-driver/Cargo.toml
index 2163620..7856356 100644
--- a/openvaf/openvaf-driver/Cargo.toml
+++ b/openvaf/openvaf-driver/Cargo.toml
@@ -27,6 +27,7 @@ backtrace-ext = "0.2.1"
 backtrace = "0.3.68"

 mimalloc = { version = "*", default-features = false}
+llvm-sys = { version = "181.2.0", features = ["prefer-dynamic"] }

 [dev-dependencies]
 xshell = "0.2.3"

[Kreijstal]

I finally made it build with llvm18... https://github.com/arpadbuermen/OpenVAF/pull/5 yay!

[arpadbuermen]

Great. Make a pull request. I will try it out.