Getting Simulations to work using OSDI files
Closed this issue · 16 comments
Not having luck getting @dwarning Verilog examples to work using OSDI files. Can you spot what I'm doing wrong?
I made multiple netlists as well as use dwarning's test netlists and still no luck.
I hope it's easier to use the OSDI files instead trying to build/link/compile the Verilog files. I deleted all the MS SW after Openvaf became unsupported.
There is something wrong with the provided OSDI file. It doesn't load on my machine too (Ngspice-43 using Arch(Manjaro) Linux). The Ngspice gives the following error:
Error: Library /home/vvk/.qucs/EKV3_osdi_test_prj/ekv3.osdi couldn't be loaded!
Error opening osdi lib "/home/vvk/.qucs/EKV3_osdi_test_prj/ekv3.osdi": /home/vvk/.qucs/EKV3_osdi_test_prj/ekv3.osdi: invalid ELF header
Error: Library /home/vvk/.qucs/EKV3_osdi_test_prj/ekv3.osdi couldn't be loaded!
This is surely not Qucs-S error. You should try to compile the OSDI file locally. Closing this issue as "not a bug" because this is not related to Qucs-S GUI. I am not considering the extension of Verilog-A/OSDI support in the near future.
@ra3xdh @tomhajjar
For me it is interesting from which source your osdi files stem. Are they self compiled or from my repository . Which compiler was used?
I used your repository for the osdi files. I deleted all the MS SW required after Openvaf became unsupported so I cannot create them anymore. My only goal is to create more test projects for new users.
My only goal is to create more test projects for new users.
The tunnel diode project from #411 is sufficient. The Verilog-A support is required only for a few academic users. I think the distribution of binary OSDI files is not a good practice. The OpenVAF still be developed by another developer in this fork: https://github.com/arpadbuermen/OpenVAF It's need to check if everything compiles using this version.
I redid the Tunnel diode project. I made two projects to make it easier for new users. Traditional that makes a Verilog library device and odsi only including making a sub-circuit with a schematic symbol.
I had to reload a number of MS packages plus downloaded the latest openvaf.
https://fides.fe.uni-lj.si/openvaf/download/
null
I redid the Tunnel diode project. I made two projects to make it easier for new users. Traditional that makes a Verilog library device and odsi only including making a sub-circuit with a schematic symbol.
I had to reload a number of MS packages plus downloaded the latest openvaf. https://fides.fe.uni-lj.si/openvaf/download/
did you try this openvaf-reloaded pull request, you don't need msvc
arpadbuermen/OpenVAF#9
git clone https://github.com/OpenVAF/OpenVAF-Reloaded.git openvaf
cd openvaf
cargo install --path openvaf/openvaf-driver/
you can do this under msys2, but not under clang so windows on arm is not supported yet..
Where is this "new" OpenVAF.exe for Windows?
I would need to test it on a different Windows PC that doesn't have all the MS tools installed.
Where is this "new" OpenVAF.exe for Windows?
I would need to test it on a different Windows PC that doesn't have all the MS tools installed.
You don't need ms tools, you can just use msys2 toolchain without installing any ms tools, you can run this msys2 toolchain completely portably, no installation neeeded.
But okay, one way to get msys2 toolchain would be to do the following:
either use the installer https://github.com/msys2/msys2-installer/releases/download/2024-11-16/msys2-x86_64-20241116.exe or decompress https://repo.msys2.org/distrib/x86_64/msys2-base-x86_64-20241116.tar.xz if you don't like installing (there is also https://github.com/msys2/msys2-installer/releases/download/2024-11-16/msys2-base-x86_64-20241116.sfx.exe) which is a self decompressing .exe
then open the ucrt64 enviroment
type
pacman -S mingw-w64-ucrt-x86_64-rust mingw-w64-ucrt-x86_64-clang mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-llvm git base-devel
and
git clone https://github.com/Kreijstal/OpenVAF.git openvaf
git checkout small_hot_fix_msys2
cd openvaf
cargo install --path openvaf/openvaf-driver/
you will have openvaf-r.exe on your cargo install directory. (which you might have to add to PATH)
So this won't be a "portable" single file like the present version of OpenVAF.exe for Windows?
So this won't be a "portable" single file like the present version of OpenVAF.exe for Windows?
It requires only 1 file which is llvm dll the rest should be available on Windows
ntldd OpenVAF/target/release/openvaf-r.exe
bcrypt.dll => C:\Windows\SYSTEM32\bcrypt.dll (0x00000211142a0000)
ntdll.dll => C:\Windows\SYSTEM32\ntdll.dll (0x0000021122240000)
shell32.dll => C:\Windows\SYSTEM32\shell32.dll (0x0000021122240000)
userenv.dll => C:\Windows\SYSTEM32\USERENV.dll (0x0000021122e20000)
ws2_32.dll => C:\Windows\SYSTEM32\WS2_32.dll (0x0000021122f90000)
ADVAPI32.dll => C:\Windows\SYSTEM32\ADVAPI32.dll (0x0000021122cf0000)
KERNEL32.dll => C:\Windows\SYSTEM32\KERNEL32.dll (0x0000021122cf0000)
libLLVM-19.dll => E:\msys64\ucrt64\bin\libLLVM-19.dll (0x00000211239d0000)
ole32.dll => C:\Windows\SYSTEM32\ole32.dll (0x0000021122b40000)
OLEAUT32.dll => C:\Windows\SYSTEM32\OLEAUT32.dll (0x0000021123610000)
bcryptprimitives.dll => C:\Windows\SYSTEM32\bcryptPrimitives.dll (0x0000021122240000)
So this won't be a "portable" single file like the present version of OpenVAF.exe for Windows?
It requires only 1 file which is llvm dll the rest should be available on Windows ntldd OpenVAF/target/release/openvaf-r.exe bcrypt.dll => C:\Windows\SYSTEM32\bcrypt.dll (0x00000211142a0000) ntdll.dll => C:\Windows\SYSTEM32\ntdll.dll (0x0000021122240000) shell32.dll => C:\Windows\SYSTEM32\shell32.dll (0x0000021122240000) userenv.dll => C:\Windows\SYSTEM32\USERENV.dll (0x0000021122e20000) ws2_32.dll => C:\Windows\SYSTEM32\WS2_32.dll (0x0000021122f90000) ADVAPI32.dll => C:\Windows\SYSTEM32\ADVAPI32.dll (0x0000021122cf0000) KERNEL32.dll => C:\Windows\SYSTEM32\KERNEL32.dll (0x0000021122cf0000) libLLVM-19.dll => E:\msys64\ucrt64\bin\libLLVM-19.dll (0x00000211239d0000) ole32.dll => C:\Windows\SYSTEM32\ole32.dll (0x0000021122b40000) OLEAUT32.dll => C:\Windows\SYSTEM32\OLEAUT32.dll (0x0000021123610000) bcryptprimitives.dll => C:\Windows\SYSTEM32\bcryptPrimitives.dll (0x0000021122240000)
So strictly speaking no it's not compiled statically, in practice if you need to move it somewhere, just cooy the binary and the dll and place it on the same directory
@Kreijstal : I think correct order should be:
git clone https://github.com/Kreijstal/OpenVAF.git openvaf
cd openvaf
git checkout small_hot_fix_msys2
cargo install --path openvaf/openvaf-driver/
But a trial belong this recipe fails:
Compiling osdi v0.0.0 (C:\msys64\home\warning\openvaf\openvaf\osdi)
error: No suitable version of LLVM was found system-wide or pointed
to by LLVM_SYS_191_PREFIX.
Consider using `llvmenv` to compile an appropriate copy of LLVM, and
refer to the llvm-sys documentation for more information.
llvm-sys: https://crates.io/crates/llvm-sys
llvmenv: https://crates.io/crates/llvmenv
--> C:\Users\warning.cargo\registry\src\index.crates.io-6f17d22bba15001f\llvm-sys-191.0.0\src/lib.rs:529:1
|
529 | / std::compile_error!(concat!(
530 | | "No suitable version of LLVM was found system-wide or pointed
531 | | to by LLVM_SYS_",
532 | | env!("CARGO_PKG_VERSION_MAJOR"),
... |
539 | | llvmenv: https://crates.io/crates/llvmenv"
540 | | ));
| |__^
You are sure to use llvm19? Was it not 18?
@Kreijstal : I think correct order should be:
git clone https://github.com/Kreijstal/OpenVAF.git openvaf cd openvaf git checkout small_hot_fix_msys2 cargo install --path openvaf/openvaf-driver/
But a trial belong this recipe fails:
Compiling osdi v0.0.0 (C:\msys64\home\warning\openvaf\openvaf\osdi) error: No suitable version of LLVM was found system-wide or pointed to by LLVM_SYS_191_PREFIX.
Consider using `llvmenv` to compile an appropriate copy of LLVM, and refer to the llvm-sys documentation for more information. llvm-sys: https://crates.io/crates/llvm-sys llvmenv: https://crates.io/crates/llvmenv--> C:\Users\warning.cargo\registry\src\index.crates.io-6f17d22bba15001f\llvm-sys-191.0.0\src/lib.rs:529:1 | 529 | / std::compile_error!(concat!( 530 | | "No suitable version of LLVM was found system-wide or pointed 531 | | to by LLVM_SYS_", 532 | | env!("CARGO_PKG_VERSION_MAJOR"), ... | 539 | | llvmenv: https://crates.io/crates/llvmenv" 540 | | )); | |__^
You are sure to use llvm19? Was it not 18?
do pacboy -S llvm:p clang:p
And yes you are right llvm18 was fine, you can just use the ci branch instead, the thing is msys2 upgraded from llvm18 to llvm19 so I thought I had to update to llvm19 but it turns out llvm-sys 181.1.1 is backwards compatible. so ci was just fine..
just do cargo clean
pacboy -S llvm:p clang:p --needed
git clone https://github.com/Kreijstal/OpenVAF.git openvaf
cd openvaf
git checkout ci
cargo install --path openvaf/openvaf-driver/
I got 18.1.8.1from first pacman cmd. Switching to ci branch made the job.
General remark: Switching to newest llvm version brings not really advantage under users point of view.
I got 18.1.8.1from first pacman cmd. Switching to ci branch made the job. General remark: Switching to newest llvm version brings not really advantage under users point of view.
that is okay, warning whenever you do pacman -Syu you will "upgrade" all of your msys2 packages (this will delete your shared library llvm18 and replace it with llvm19), so you will get llvm19 instead, this makes openvaf-r not run anymore (since at compile time it was linked to llvm18), if you try to compile again, it will not work, I thought it was a bug, but you will have to do 'cargo clean', and compile again. I thought they were incompatible versions, but it turns out, it was just rust cache acting.
So if you feel like you want to "just get the .exe" id recommend simply copying the .exe and the llvm.dll you install from pacman