Hi,

I'm trying to create a measuring device in Verilog-A that prints its terminal voltages and currents during the simulation, along with the independent variable. This is quite straightforward in transient ($abstime), DC (passing in as parameter), and thermal ($temperature), but for AC I seem unable to measure the frequency.

I've tried code such as:

Code:

electrical f;

...

analog begin

  ...

  V(f) <+ laplace_nd(ac_stim(), {1}, {0, 1});
  $strobe("frequency = %g", V(f)/`M_TWO_PI);

  ...

end // analog 

But the only return value I ever got was 0.0. I've also tried this in multiple tools (using different Verilog-A compilers) but none provided the desired results.

I've also tried to use an external small signal source and filter, so the frequency-dependent signal would only be probed by the Verilog-A module, but that didn't work either.

Marq

None of these approaches will work. Verilog-A models are not actually evaluated during the AC analysis. Rather, a DC analysis is run and the model is linearized about the DC operating point. It is linearization that is used during the AC analysis. Any attempt to access or create a variable that contains the frequency is doomed to fail. Also, printing during an AC analysis is not possible. If you perform an AC analysis that sweeps some parameter that affects the operating point, then will appear to print during the AC analysis, but it is actually printing during the DC operating point analysis that precedes each AC step.

-Ken

That is strange. It may be that your simulator (which appears to be Spectre) is actually evaluating the model at every frequency point. Conceptually that is not necessary. However, since it is evaluating the model at every frequency point, then it is probably also running a DC analysis (it better, because as you have shown, by evaluating the model you can change its behavior, and hence the DC operating point, on every step). Anyway, with this being the case you should ignore my comments on the printing. However, it is still not possible to access the frequency.

-Ken

At a minimum it is evaluating the model between every AC point. The question in my mind is if the simulator is actutually performing a DC analysis. One could determine that by changing the model on each step in a way that it affected the operating point, and then print the operating point and see if it changed. For example, one could write a model for a resistor whose resistance changed on every step, then drive it with a current source and print the output voltage across the resistor on each step. If it changed, then presumably it is doing a full DC oppoint analysis between each AC point, and so will compute the right answer.

-Ken

So now the question has changed from whether you can access the frequency to whether you should be able to. My answer has always been no. And my reasons are:
1. It is very difficult for the user to formulate a frequency domain model correctly.
2. It is very difficult to implement a frequency domain modeling capability in the simulator that operates properly and gives good results in the transient analysis.
3. It is not very useful; there are very few models that are both easy to describe in the frequency domain and hard to describe in the time domain.

Issue number 1 is about causality. It is very easy to describe a model that is non-causal when working in the frequency domain. Such a model is impossible to include in any meaningful way into a transient analysis, and of course produces non-physical results. For example, many people try to model skin effect by creating a resistor with a resistance that is proportional to sqrt(f), but the result is non-causal. What really is needed is an impedance that is proprotional to sqrt(jω). Some of this can be mitigated by not allowing access to f, only to jω, and by avoiding the temptation to provide non-analytic functions, such as real(), imag(), conj(), etc. These things help, but it is not clear that completely solve this problem.

Issue number 3 is something I have observed over time. Most models that are easy to write in the frequency domain, like capacitors and inductors, are lumped, and they are also easy to write in the time domain. Models that are distributed are difficult to write in the time domain, but except in a few exceptional cases, are also difficult to write in the frequency domain. The exceptions are things like ideal delay, skin effect, and the like. These special cases can be more easily handled by both the user and the simulator by providing built-ins in the simulator. An example is the absdelay() function already provided in the language.

-Ken

Not for Laplace, but perhaps for absdelay() and the z filters. In any case, the model does not have to be reevaluated, just the function. I suspect they evaluate the model simply because of the strobe functions.

-Ken

Another thing that would be nice would be to have access to results in the frequency domain so that if all you were looking for was the 3dB frequency you could end the simulation once you found it..
However it might be better to add a language (TCL?) like MDL to use with the Simulator and the Verilog-A(MS) design description for use in managing the simulations.. TCL has been OK for Verilog-AMS - at least in the Time domain runs and for what I have tried so far.

jbd ιβδ

From the standpoint of a standard Spice ac analysis, models aren't allowed to change (and aren't evaluated) during the frequency sweep.  The circuit is frozen and linearized.  So, I would argue that Cadence made the wrong choice in allowing anything in the model to change for subsequent points of an ac analysis (I'm ambivalent about whether the $strobe statements should be issued).  For a compact model, the simulator should extract the code it needs for an ac analysis and not run the analog block directly.

For behavioral models, though, I guess it's not so easy to determine the "right thing" to do.