The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Design Languages >> Verilog-AMS >> Printing frequency in AC output
https://designers-guide.org/forum/YaBB.pl?num=1156512831

Message started by Marq Kole on Aug 25^th, 2006, 6:33am

Title: Printing frequency in AC output
Post by Marq Kole on Aug 25^th, 2006, 6:33am

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

Title: Re: Printing frequency in AC output
Post by ACWWong on Aug 25^th, 2006, 9:33am

this is quite interesting.... i tried it myself, but like you got 0.... and there is no simple $absfrequency....

I guess you are wanting to do something with the freq variable within your code, so a practical (rather than neat) solution would be to use say:

analog begin
@(initial_step) begin
acfrq = -2;
end
acfrq = acfrq+1;
$strobe("step=%g",acfrq);
end

So setting up your ac sweep from 1 to 10 Hz in steps of 1 will give you the frequency variable printed correctly.... Obviously for log sweeps etc. you'll have to tweak the acfrq=acfrq+1 line to get the right mathematical increments. The initial value needs to be 2 values lower than the initial start point of the ac sweep, as spectre seems to call the veriloga code twice before begining the proper frequency sweep (something to do with computing the dc solution first i guess).

Anyway if you only wanted the frequncy varibale for post-processing, the calculator xval function would work well in OCEAN.

Alternatively i think you might find a neater solution elsewhere... perhaps something to do with modeling skin effect in inductors (as resistance is a function of the frequency variable)would be give you some good ideas ?

cheers

aw

Title: Re: Printing frequency in AC output
Post by Ken Kundert on Aug 25^th, 2006, 11:11am

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

Title: Re: Printing frequency in AC output
Post by ACWWong on Aug 25^th, 2006, 11:24am

Ken Kundert wrote on Aug 25^th, 2006, 11:11am:

hi Ken,

i'm a bit confused with what i see when i just run an ac sweep from 1 to 10 Hz in steps of 1 Hz and use the veriloga code i posted previously. In my spectre.log is get:

****************************************
AC Analysis `ac': freq = (1 Hz -> 10 Hz)
****************************************

Notice from spectre during AC analysis `ac'.
No outputs found. Loosening output filter criterion to `lvl'.

sacfrq=-1
sacfrq=0
sacfrq=1
sacfrq=2
ac: freq = 2 Hz (11.1 %), step = 1 Hz (11.1 %)
sacfrq=3
ac: freq = 3 Hz (22.2 %), step = 1 Hz (11.1 %)
sacfrq=4
ac: freq = 4 Hz (33.3 %), step = 1 Hz (11.1 %)
sacfrq=5
ac: freq = 5 Hz (44.4 %), step = 1 Hz (11.1 %)
sacfrq=6
ac: freq = 6 Hz (55.6 %), step = 1 Hz (11.1 %)
sacfrq=7
ac: freq = 7 Hz (66.7 %), step = 1 Hz (11.1 %)
sacfrq=8
ac: freq = 8 Hz (77.8 %), step = 1 Hz (11.1 %)
sacfrq=9
ac: freq = 9 Hz (88.9 %), step = 1 Hz (11.1 %)
sacfrq=10
ac: freq = 10 Hz (100 %), step = 1 Hz (11.1 %)
Accumulated DC solution time = 0 s.
Intrinsic ac analysis time = 10 ms.
Total time required for ac analysis `ac' was 10 ms.

are you saying for every ac sweep point, a dc op point simulation is being completed ? surely there is only 1 dc op point simulation at the begining ??

cheers

aw

Title: Re: Printing frequency in AC output
Post by Ken Kundert on Aug 25^th, 2006, 11:38am

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

Title: Re: Printing frequency in AC output
Post by ACWWong on Aug 25^th, 2006, 11:50am

Ken Kundert wrote on Aug 25^th, 2006, 11:38am:

Thanks ken,

Anyway just for my curiousity i have run the following veriloga code, to remove the acfrq=acfrq+1 so that nothing in the model changes each time it is evaluated, ie no reason to redo the dcop...

module freq;

electrical a; //needed to present an output for spectre to be happy

analog begin

$strobe("bob");

end // analog

endmodule

And when i ran the ac sweep 1 to 10 in steps of 1 i get:

****************************************
AC Analysis `ac': freq = (1 Hz -> 10 Hz)
****************************************

Notice from spectre during AC analysis `ac'.
No outputs found. Loosening output filter criterion to `lvl'.

bob
bob
bob
bob
ac: freq = 2 Hz (11.1 %), step = 1 Hz (11.1 %)
bob
ac: freq = 3 Hz (22.2 %), step = 1 Hz (11.1 %)
bob
ac: freq = 4 Hz (33.3 %), step = 1 Hz (11.1 %)
bob
ac: freq = 5 Hz (44.4 %), step = 1 Hz (11.1 %)
bob
ac: freq = 6 Hz (55.6 %), step = 1 Hz (11.1 %)
bob
ac: freq = 7 Hz (66.7 %), step = 1 Hz (11.1 %)
bob
ac: freq = 8 Hz (77.8 %), step = 1 Hz (11.1 %)
bob
ac: freq = 9 Hz (88.9 %), step = 1 Hz (11.1 %)
bob
ac: freq = 10 Hz (100 %), step = 1 Hz (11.1 %)
Accumulated DC solution time = 10 ms.
Intrinsic ac analysis time = 0 s.
Total time required for ac analysis `ac' was 10 ms.

so its still evaluating the DC before each ac step... pretty bizarre ?
Anyway the original code will still give you the variable acfrq which in incremented in tandem with the ac freq (albeit there is a hidden dc op beofre every ac point, which can't be turned off ?!?!).

cheers
aw

Title: Re: Printing frequency in AC output
Post by Ken Kundert on Aug 25^th, 2006, 6:28pm

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

Title: Re: Printing frequency in AC output
Post by Marq Kole on Aug 28^th, 2006, 12:12am

Ken, AW,

Thanks for the replies. I now see that I've been a bit naive, as the signal in the frequency domain is of course a complex number, not a real value like in transient and DC. So all my ideas to extract the frequency were doomed to failure becuase Verilog-A cannot handle the complex results that should have come from these expressions.

I guess that for full support of AC the language needs to be extended. Would that also help for non-linear frequency domain modelling and simulation (RF)?

Marq

Title: Re: Printing frequency in AC output
Post by Ken Kundert on Aug 28^th, 2006, 8:49am

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

Title: Re: Printing frequency in AC output
Post by ACWWong on Aug 29^th, 2006, 5:10am

Ken Kundert wrote on Aug 25^th, 2006, 6:28pm:

Ken, I did what you suggested and confirmed that the verilogA is model is evaluated at every AC step by Spectre, but the DC is NOT evaluated. So its NOT possible to modify the DC op point on the fly within the ac sweep, its only evaluated at the begining (as i have always understood it). Does the veriloga model have to be evaluated every ac step for things like the laplace to work ?

Title: Re: Printing frequency in AC output
Post by Ken Kundert on Aug 29^th, 2006, 6:20am

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

Title: Re: Printing frequency in AC output
Post by Geoffrey_Coram on Aug 29^th, 2006, 8:32am

Ken Kundert wrote on Aug 28^th, 2006, 8:49am:

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.

I can howeer see Marq's point that, for an "instrumentation module" ie one that prints out information about the circuit, it is nice to be able to print the frequency value. I could imagine providing a %code to give the frequency.

Title: Re: Printing frequency in AC output
Post by jbdavid on Aug 29^th, 2006, 11:04am

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 ιβδ

Title: Re: Printing frequency in AC output
Post by Ken Kundert on Aug 29^th, 2006, 12:30pm

This question has exposed an area in the Verilog-A LRM that is ambiguous. There is no discussion about the simulation cycle for AC analysis. Thus it is not clear even if the AC analysis code should be evaluated at every step of the AC analysis. Cadence clearly takes a middle ground, where they evaluate the model but not actually perform a DC analysis, but one could imagine the LRM stating that either no code is evaluated or a full DC analysis is required on every step of an AC analysis if the DC operating point could change.

-Ken

Title: Re: Printing frequency in AC output
Post by Geoffrey_Coram on Aug 30^th, 2006, 6:32am

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.

Title: Re: Printing frequency in AC output
Post by Ken Kundert on Aug 30^th, 2006, 11:27am

Agreed. Cadence should reinitialize every local variable to 0 before each non-transient step. That way, even if the models are re-evaluated at every step, they would behave exactly the same.

-Ken

Title: Re: Printing frequency in AC output
Post by jbdavid on Aug 30^th, 2006, 10:58pm

What would prevent a person from doing a parameter sweep with just a DCop and SinglePoint AC, where the AC frequency was a little different at each step..

BTW I want a simulator where I can do

run 20ns
AC(tb.dut.in_p,tp.dut.in_n) sweep Freq from 10K to 100G log 20
run 30ns

Title: Re: Printing frequency in AC output
Post by Marq Kole on Aug 31^st, 2006, 12:08am

Geoffrey_Coram wrote on Aug 29^th, 2006, 8:32am:

Ken Kundert wrote on Aug 28^th, 2006, 8:49am:

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.

I've been giving this some thought: with respect to the model safety aspects and limited to small-signal frequency domain, I can only see two extensions:

display format codes that allow one to output AC values of signals - but you might want additional formatters for getting polar representation, or only real part, imaginary part, phase or magnitude,
built-in S-parameter and Y-parameter models, along the lines of the Spice primitives mentioned in Annex E, using either a file or array just like the $table_model.

I really like these instrumentation modules because they allow me to compare the results in various simulators. Think of compact model development or IP library development.

Title: Re: Printing frequency in AC output
Post by Marq Kole on Aug 31^st, 2006, 1:21am

One thing I forgot in the above list (but in a wat already mentioned by Geoffrey):

a display code to get the frequency, along the same line as the %M code for a hierachical name - without an actual argument, but with support for formatting codes similar to those for real numbers.

An additional option could be to have similar display output, but then during the small-signal noise analysis: again purely for instrumentation purposes.

Title: Re: Printing frequency in AC output
Post by Ken Kundert on Aug 31^st, 2006, 9:22am

Marq,
I don't believe that an AHDL like Verilog-A or Verilog-AMS is the right language for this kind of post analysis analysis (or instrumentation modules as you call them). They are not a good fit. As you have already noticed, you would need to add complex arithmetic to the language, but that is just the beginning of the changes that would be needed. It completely changes the character of the language.

I spent a lot of time on this issue while I was at Cadence and developed the idea of having a measurement description language (or MDL) as a natural complement to the HDLs. Cadence eventually released SpectreMDL, but it is a very limited and primitive version of what was originally envisioned. As Jonathan proposed elsewhere in this Forum, it would be helpful to have a standardized MDL. I've often wondered if there would be any interest in developing and implementing such a standard. I believe it would be incredibly useful, but it would also be a lot of work.

-Ken

P. S. for Jonathan,
Spectre can do what you want. I give an example in section 3.4.4 (pg. 113) in my Spice and Spectre book.

Title: Re: Printing frequency in AC output
Post by John O Donovan on Aug 31^st, 2006, 10:07am

Hi,

If you want to run a transient analysis to 30ns and use the oppoint at 20ns to run an AC type (ac, noise, sp, xf) analysis you can also use the 'actimes' and 'acnames' transient analysis parameters, i.e.

ac1 ac param=freq start=10K stop=100G log=20
tran1 tran stop=30ns actimes=[20ns] acnames=[ac1]

'actimes' and 'acnames' are vectors so you can run multiple analyses at multiple times during the tran.

Regards,
John

Title: Re: Printing frequency in AC output
Post by jbdavid on Sep 1^st, 2006, 11:25pm

That would be the Spectre way of doing It.. I was thinking more of NCsim-AMS