pascalkuthe / OpenVAF

An innovative Verilog-A compiler
https://openvaf.semimod.de/
GNU General Public License v3.0
113 stars 15 forks source link

Crash on `aarch64` and `x86_64` when compiling psp103_nqs.va #89

Closed hpretl closed 8 months ago

hpretl commented 8 months ago

Log file is attached.

openvaf-crash-1697364896.log

hpretl commented 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.

hpretl commented 8 months ago

There is also a crash on x86_64, log attached:

openvaf-crash-1697365627.log

hpretl commented 8 months ago

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
metroid120 commented 8 months ago

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.

hpretl commented 8 months ago

Good point, thanks! I'll try to build LLVM-15 then. I will report back how this went.

hpretl commented 8 months ago

I tested various combination:

No idea how to continue.

metroid120 commented 8 months ago

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.

hpretl commented 8 months ago

I used this one (just comment the right one of the first two lines).

Dockerfile.txt

hpretl commented 8 months ago

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?

metroid120 commented 8 months ago

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👍

metroid120 commented 8 months ago

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.

Dockerfile.txt

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

hpretl commented 8 months ago

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
hpretl commented 8 months ago

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
hpretl commented 8 months ago

Pinging @mrhighvoltage to chime in.

metroid120 commented 8 months ago

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

hpretl commented 8 months ago

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
hpretl commented 8 months ago

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
MrHighVoltage commented 8 months ago

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 :)

hpretl commented 8 months ago

@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?

hpretl commented 8 months ago

Here is a PR https://github.com/pascalkuthe/OpenVAF/pull/90 to fix above issues.

metroid120 commented 8 months ago

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.

hpretl commented 8 months ago

Not yet; I'll test it, but this will take quite a few days, since I have to (re)build our full Docker image.

hpretl commented 8 months ago

@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!

metroid120 commented 8 months ago

I think the issue can be closed for now