limexp function

[justinrf]

I had some issues compiling a VA model from a commercial PDK.

It seems OpenVAF didn’t know how to handle the limexp function. I don’t think limexp should be included as an analog function. Here’s what I did that seems to work:

openvaf/hir_def/src/builtin.rs
Remove line 158 (| BuiltIn::limexp)

In
openvaf/hir_ty/src/validation/body.rs, line 561 and 562

_ if call.is_analog_operator() && call != BuiltIn::ddx && call != BuiltIn::limexp
|| call.is_analog_operator_sysfun() =>

I needed to force static linking against LLVM 18 to make sure the binary has no runtime shared library dependency (which might be specific to my system)
openvaf/mir_llvm/Cargo.toml line 13
llvm-sys = {version="181.1.1"}

Anyway - I can compile the model now.

[Kreijstal]

hmm there should be no difference between static and dynamic linking unless you don't have it on your package manager, which platform was this?

[justinrf]

In fact, I don't have it on my package manager. I use Rocky 9.5, which comes with LLVM 20, so I had to manually install V18 - which is what made me think that this part of the problem was my setup. The rest of it, though...

[Kreijstal]

you shouldn't need to downgrade, you can use a higuer version of llvm if available. that is the point of the dynamic linking. do you get an error when using llvm20?

[justinrf]

Yeah - ok - I can try again with LLVM 20. I was getting was a version symbol mismatch. When I built prefer-dynamic with LLVM 20, the binary linked against libLLVM.so.18. At run time that library exported the symbol LLVM_20 and not LLVM_18, so it failed.

Sure, I can probably mess about and get it to run in LLVM 20, but that really isn't the point. The point was the bug in limexp that killed the VA compile.

[gjcoram]

I don’t think limexp should be included as an analog function.

Well, if you just implement it as exp() then it wouldn't need to be. If you implement the restrictions on the iteration-to-iteration changes that are intended to improve convergence, you might need it to be an analog function.

…

On Sun, Mar 29, 2026 at 4:12 AM justinrf ***@***.***> wrote: Yeah - ok - I can try again with LLVM 20. I was getting was a version symbol mismatch. When I built prefer-dynamic with LLVM 20, the binary linked against libLLVM.so.18. At run time that library exported the symbol LLVM_20 and not LLVM_18, so it failed. Sure, I can probably mess about and get it to run in LLVM 20, but that really isn't the point. The point was the bug in limexp that killed the VA compile. — Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=ACYQ2FRTWZLA2EYNEXZ5Y234TDSGNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGY2DKMJVUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-16364515>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYQ2FRWFKVGAC664FFLQHD4TDSGNAVCNFSM6AAAAACXDQS43SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZWGQ2TCNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** .com>

[justinrf]

Technically, that's true, but somewhat misses the point.

At convergence, limexp(x) = exp(x), so all fine and dandy. But the point of limexp's is not to produce a different answer, it's to help the solver to that answer without divergence. The limiting changes what the solver sees during intermediate iterations, not the converged result.

limexp exists is to fix cases where exp alone causes the solver to diverge before reaching that result. Without the state-based limiting, circuits with exponential I-V relationships (diodes, BJTs) are prone to convergence failures, which is probably why the fab (not me!) used it in their model deck.

There's no harm in making a stateful limexp, except time, and the fix I proposed did what I needed it to do - which was to get a fab model deck working.

[gjcoram]

Doesn't having limexp be an analog function mean that, when it's in an if statement, the condition has to be a constant expression? That is, you can have
if ($param_given(bv)) begin
// some limexp calculation
end
but you can't have
if (V(a,c) > 0) begin
// some limexp calculation
end
In the latter case, if V(a,c) < 0, then there's no call to limexp to set the "state" value for that iteration, and then the next time V(a,c) > 0, it's not clear what state value to use for the previous iteration.

Does the limexp in the foundry model live in an if-statemement with a bias-dependent condition?