Website and questions about next OpenVAF version

[adrienluitot]

Hello everyone!

Website
Just to tell you that I imported the OpenVAF website to the organisation and created a GitHub Page: https://openvaf.github.io!

Features
Some questions about the next OpenVAF version:

• Will it manage LLVM 15 to 18 or only 18?
• Will it manage both OSDI v0.3 and v0.4, or only v0.4? (I think an option could be nice to ensure retro-compatibility, but I don't know how hard it is to implement)

Versioning
And what should be the next official version? Should we:

1. keep the original Ubuntu style: 24.12.0 (if in 2024-12)
2. restart: 1.0.0
3. rise from ashes: 2.0.0

(I personally prefer option 3, because I like the good old 1.0.0 style, and I think a 2.0 version is good for "marketing". Like "OpenVAF 2.0 is here!")

[adrienluitot]

Hello everyone, it's been a while OpenVAF hasn't move. I was wondering, @Kreijstal and @arpadbuermen, if you are still on it?
I hope OpenVAF-reloaded won't need an OpenVAF-reloaded-reloaded...

[Kreijstal]

I am simply rebasing my changes around whatever @arpadbuermen does, I don't think he follows any versioning yet.

[Kreijstal]

That's great!! I like it when projects like these get revived. I guess we can change the page and news a little bit to tell what has happened. My side of the story is:
I tried to compile openvaf on arch and couldn't normally and then I realized it had a fixed dependency on LLVM15 because it used the old pass manager, it took a long effort but finally ported openvaf to llvm18 (it was not easy and had to fix some bugs), made it compile (with bugs), then fixed the bugs of the porting, then added support for msys2, and CI and so on.

I noticed @arpadbuermen had made a fork with a lot of changes and revived it under a different name, and I saw @gjcoram also had fixed lots of bugs, I noticed they did follow different trees so I thought they should collaborate, I of course rebased all my changes on top of arpads fork. So it is easy to merge. And I think that is a summary of my side of the story.

[adrienluitot]

Thanks for your reply! It could be cool if Arpad could give a feedback.
That would be awesome to have a clean version that could be shared.

[arpadbuermen]

I am still working on it. Mainly on reverse engineering MIR and HIR, and on performance issues. After the release of Ngspice 44 I stopped supporting OSDI 0.3 because 0.4 is almost binary compatible with 0.3 and most software using OpenVAF (Ngspice and VACASK) moved to support 0.4. It is easy to adapt software using OSDI 0.3 to using OSDI 0.4 (see Ngspice).

As far as I am concerned at this point there are no critical bugs, only requests for Verilog-A features that are not used in compact models, so they are not my priority. OpenVAF is primarily a compact model compiler. Extending it to full Verilog-A would be a hard task because OpenVAF's internal structures would need significant changes.

Until I have time to thoroughly test the LLVM18 version on actual circuits I will stick with LLVM15. As it turned out in the past, even though OpenVAF passed all its tests they did not catch several serious bugs.

I am releasing LLVM15 OpenVAF binaries for Windows and Linux on my fork's page (a link to https://fides.fe.uni-lj.si/openvaf/download). You are welcome to link to this server for LLVM15-based binaries. You are also welcome to incorporate my changes into the LLVM18 port.

OpenVAF-reloaded includes all known fixes out there (by Geoffrey Coram, Dietmar Warning, and me) with the exception of LLVM18 support.

[Kreijstal]

I wonder if there can be tests written that probe for these bugs