Open dwarning opened 1 year ago
The reason $realfreq is not defined in Verilog-A/MS is that it makes no sense in transient analyses. Verilog-A is designed so that models can be run in all possible analyses. $realfreq undermines that.
Even in the AC analyses $realfreq is very dangerous. It is very difficult to write models with $realfreq in the frequency domains that are physical. Specifically, if you do not write the model satisfying very rigid and non-obvious constraints, your model will be non-causal. For example, you might want to use sqrt($realfreq)
to model skin effect, but that results in a model that is non-causal.
Please do not consider adding $realfreq as an enhancement. It will cause nothing but trouble. It is bad enough that people can write models that do not conserve charge; don't also allow them to write models that cannot be simulated in transient analysis and non-causal models.
The universal usability of certain functions and operators in all analysis types is not hold yet in Verilog-A. In case of $abstime we get simulator time in transient analysis. Why not get the frequency in ac analysis?
The noise function are an other example. If I understand the LRM correct they deliver nothing except for ac and noise analysis. And in their simulator implementation nothing other as frequency is used. In your consequence they should deliver a kind of inverse laplace transform for time domain simulation. What would be nice.
I agree that modelling in frequency domain with the frequency value should restricted. In MAST times the simvar freq was restricted to ac analysis and 0 otherwise. This should possible for today's modern compiler/simulator too.
But it is a feature request and for openVAF other points as noise model and laplace filter implementation are more actual and important.
The small signal stimulus functions were added to Verilog-A because they are needed and they are well behaved in all analyses. They are in no way a user trap like $realfreq would be.
As far as I can see $realfreq would be useful in two situations:
The first you can already do using the laplace functions, and they work in all analyses and they are consistent in all analyses.
The second is extremely difficult to do without creating non-causal models, which is a user trap. Also, it is quite difficult evaluate such a model in the time domain. The simulator could, as you suggest, simply set $realfreq to zero in time domain analyses, but now the AC behavior and transient behavior no longer agree, which is another user trap.
Finally, without complex arithmetic, $realfreq is only useful for modeling independent sources. In my many years of simulation that is a feature I never needed or wanted.
When you are asking for $realfreq support, you are also implicitly asking for complex number support as well as inverse Laplace transform support for arbitrary expressions and causality checking. That is a big ask. The last two items are very difficult to do well, and so become support headaches. And without the last two, you greatly reduce the utility of the enhancement and create confusing user traps.
Never understood why $abstime for time domain is available and $realfreq in frequency domain not in LRM. Not important, but in times of growing new noise models it would helpful.