Closed hpretl closed 8 months ago
Additional info: When compiling for aarch64
, I need to do the following when building OpenVAF
to solve a compile error:
sed -i 's/i8/u8/g' openvaf/llvm/src/initialization.rs
This is not required for x86_64
.
There is also a crash on x86_64
, log attached:
I am using this script to build OpenVAF
on Ubuntu:
#!/bin/sh
# SPDX-FileCopyrightText: 2023 Harald Pretl, IIC@JKU
# SPDX-License-Identifier: Apache-2.0
#
# Script based on a template by Markus Mueller, Semimod
# Semimod's OpenVAF is compiled and installed
apt-get -y update && apt-get -y upgrade
apt-get install -y build-essential wget git python3 rustc cargo
apt-get install -y clang clang-tools lld
apt-get install -y libclang-common-14-dev libz-dev
export LLVM_CONFIG=/usr/bin/llvm-config-14
[ ! -f /usr/bin/clang-cl ] && ln -s /usr/bin/clang-cl-14 /usr/bin/clang-cl
[ ! -f /usr/bin/llvm-lib ] && ln -s /usr/bin/llvm-lib-14 /usr/bin/llvm-lib
cd /tmp || exit
git clone https://github.com/pascalkuthe/OpenVAF
cd OpenVAF || exit
if [ "$(arch)" = "aarch64" ]; then
sed -i 's/i8/u8/g' openvaf/llvm/src/initialization.rs
fi
cargo build --release --bin openvaf
cp target/release/openvaf /usr/local/bin/openvaf
Hi Harald, I am traveling this week without laptop and do not have much time. My first guess is that you compile with the wrong llvm version.
You should use llvm version 15, else it cannot work. From a first view this looks like you compile with llvm14. Maybe you must compile llvm yourself (as in my initial Docker). Hope that helps and thank you.
Good point, thanks! I'll try to build LLVM-15 then. I will report back how this went.
I tested various combination:
jammy
) on either aarch64
or x86_64
: Crashaarch64
or x86_64
: CrashNo idea how to continue.
Harald, that is unfortunate to hear, can you please forward the Dockerfile you finally used?
This week I really cannot do much, my only hope is that maybe Pascal can say what the issue might be quicker. I propose to first fix the x86 version compilation, before we go to arch64.
In the meantime, please just use the pre compiled executable from our Downloads website. The psp model was tested with that version and it worked on many machines.
I used this one (just comment the right one of the first two lines).
Update: Using the openvaf
from your homepage I can compile the psp103_nqs.va
inside our Docker on x86_64
. So this binary works. Question is, why does it not work when I build it myself with the Dockerfile above?
Thanks for the update, it confirms that it is a compilation issue. OpenVaf is sensitive to the versions of LlVM and Rust, I am sure we can figure the issue out eventually. 1👍
Hi Harald, let us first focus on the x86 version.
With the original Dockerfile, the compiled openvaf does run the psp Verilog-A code without the error you posted. Thus, I cannot reproduce the issue.
The first difference that I see is this "sed" command you use, else the Dockerfile is pretty much identical. With this command I removed, it compiles as intended. My Dockerfile is attached again, it is very similar to yours.
I use the file as follows. I have a folder with the Dockerfile and the PSP model code directory. Then:
docker build -t vae_build .
docker run -ti -v $(pwd):/in vae_build:latest
cd /in/va_code_psp103p6
/io/OpenVAF/target/release/openvaf psp103_nqs.va
I then got the confirmation that it worked:
Finished building psp103_nqs.va in 9.68s
I now tested the recipe above on macOS, x86_64
... works.
[root@78dac1475fb9 openvaf]# /io/OpenVAF/target/release/openvaf psp103_nqs.va
Finished building psp103_nqs.va in 11.32s
I now tested the same procedure on macOS, aarch64
. I have to change
FROM quay.io/pypa/manylinux2014_x86_64:latest
to this
FROM quay.io/pypa/manylinux2014_aarch64:latest
Now, I get the following error durching the OpenVAF compiling step:
195.2 error[E0308]: mismatched types
195.2 --> openvaf/llvm/src/initialization.rs:128:9
195.2 |
195.2 125 | LLVMParseCommandLineOptions(
195.2 | --------------------------- arguments to this function are incorrect
195.2 ...
195.2 128 | b"".as_ptr() as *const i8,
195.2 | ^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
195.2 |
195.2 = note: expected raw pointer `*const u8`
195.2 found raw pointer `*const i8`
195.2 note: function defined here
195.2 --> openvaf/llvm/src/initialization.rs:26:8
195.2 |
195.2 26 | fn LLVMParseCommandLineOptions(
195.2 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
I fix this error by inserting sed -i 's/i8/u8/g' openvaf/llvm/src/initialization.rs
before the cargo build --release
. Then, compiling OpenVAF w/o errors is fine. However, when I use the resulting openvaf
executable to compile psp103_nqs.va
, I get this:
[root@c4e029ec8f1f openvaf]# /io/OpenVAF/target/release/openvaf psp103_nqs.va
LLVM ERROR: Cannot select: 0xffff88aa9d70: i32 = llround 0xffff88aaa118
0xffff88aaa118: f64 = ffloor 0xffff88aa0950
0xffff88aa0950: f64 = AArch64ISD::CSEL ConstantFP:f64<1.500000e+00>, ConstantFP:f64<5.000000e-01>, Constant:i32<12>, 0xffff88b03990:1
0xffff88c295b0: f64 = ConstantFP<1.500000e+00>
0xffff88aa10a0: f64 = ConstantFP<5.000000e-01>
0xffff88aa0f68: i32 = Constant<12>
0xffff88b03990: i32,i32 = AArch64ISD::SUBS 0xffff88a7ef18, Constant:i32<0>
0xffff88a7ef18: i32,ch = load<(load (s32) from %ir.13699)> 0xffff889fb0e8, 0xffff889facd8, undef:i64
0xffff889facd8: i64 = add nuw 0xffff88ae3068, Constant:i64<156>
0xffff88ae3068: i64,ch = CopyFromReg 0xffff88b5f418, Register:i64 %3430
0xffff88ae30d0: i64 = Register %3430
0xffff88a21968: i64 = Constant<156>
0xffff88ae3618: i64 = undef
0xffff88ae37b8: i32 = Constant<0>
In function: setup_instance_0
Aborted
Pinging @mrhighvoltage to chime in.
Nice that the x86 works now. I cannot test anything on that architecture, but I suspect the "fix" of changing u8 and i8 is just not right. While it compiles, it is not what is intended.
According to the internet, a better alternative might be to use c_string. In another project, they fixed it like this:
https://github.com/jamcha-aa/remacs/commit/8b7c7c35797c2ae7330e5f40689e56db7655a2f4
I just tested the above fix, still the same error, unfortunately:
[root@de45cee30a06 openvaf]# /io/OpenVAF/target/release/openvaf psp103_nqs.va
LLVM ERROR: Cannot select: 0xffffacaae570: i32 = llround 0xffffacaae918
0xffffacaae918: f64 = ffloor 0xffffacb5b6a0
0xffffacb5b6a0: f64 = AArch64ISD::CSEL ConstantFP:f64<1.500000e+00>, ConstantFP:f64<5.000000e-01>, Constant:i32<12>, 0xffffac9de5f0:1
0xffffac9d8850: f64 = ConstantFP<1.500000e+00>
0xffffacb5bdf0: f64 = ConstantFP<5.000000e-01>
0xffffacb5bcb8: i32 = Constant<12>
0xffffac9de5f0: i32,i32 = AArch64ISD::SUBS 0xffffacaa88b8, Constant:i32<0>
0xffffacaa88b8: i32,ch = load<(load (s32) from %ir.13699)> 0xffffac36afe8, 0xffffac36abd8, undef:i64
0xffffac36abd8: i64 = add nuw 0xffffaca71eb8, Constant:i64<156>
0xffffaca71eb8: i64,ch = CopyFromReg 0xffffacb60b48, Register:i64 %3430
0xffffaca71f20: i64 = Register %3430
0xffffac9d6f18: i64 = Constant<156>
0xffffaca72468: i64 = undef
0xffffaca72608: i32 = Constant<0>
In function: setup_instance_0
Aborted
BTW, juncap200.va
works nicely, so seems to be something PSP specific:
[root@de45cee30a06 openvaf]# /io/OpenVAF/target/release/openvaf juncap200.va
Finished building juncap200.va in 0.50s
Hey everyone!
I found that it seems like llround (long long round) only returns i64, but in your code (openvaf/mir_llvm/src/intrinsics.rs and openvaf/mir_llvm/src/builder.rs there seems to be llround defined, returning i32. But AFAIK, for i32 the correct function would be lround (long round). We are quickly checking if this is the issue, but lunch first :)
@MrHighVoltage @metroid120 Works! :-)
[root@afe817c5b48d openvaf]# /io/OpenVAF/target/release/openvaf psp103_nqs.va
Finished building psp103_nqs.va in 7.45s
@metroid120 Can we make a pull request where we fix this in your code?
Here is a PR https://github.com/pascalkuthe/OpenVAF/pull/90 to fix above issues.
Super guys, I hope we get it merged soon. Important question: Did you also test a circuit simulation with ngspice? Because I am a bit fearful that it may compile, but still not work on arch64.
Not yet; I'll test it, but this will take quite a few days, since I have to (re)build our full Docker image.
@metroid120 I can confirm and just tested that ngspice
simulation works on both x86_64
and aarch64
with the compiled PSP model :-) Please merge at your convenience!
I think the issue can be closed for now
Log file is attached.
openvaf-crash-1697364896.log