VerilogA module in a crystal oscillator simulation testbench negatively affects simulation parameters for oscillation

Another interesting observation, if I slow down the clock period of the vpulse source to the verilogA module substantially, the crystal oscillator oscillation does grow with the default simulation parameters.  However, there are these discontinuities in the signal that align with some rising and falling edges of the verilogA module input clock.

This does explain why with the faster vpulse clock period, the oscillation dies.

Again, the verilogA module is completely disconnected from anything else in the testbench except for the vpulse input source.

Dear David,

David Mulvihill said:

But when I add the verilogA module in to the testbench, even if I keep the oscillator inputs connected to the same vpwl/vdc sources, the oscillation dies when enabled. 

David Mulvihill said:

Are there other settings to prevent this from happening? As you can imagine, setting maxstep to 1/500 of the oscillator period substantially increases simulation time.  I've tried changing reltol and abstol settings, but not surprisingly, it's not helping that much, can have negative effects and is slowing down the simulation far more than constraining the maxstep size does.

I can empathize with your observations David as I've spent a considerable time designing and simulating quartz resonator based devices! 

I will add that my experience has shown that forcing the maximum integration timestep to a fraction of the expected oscillator period combined with a conservative choice for simulator accuracy is the methodology I have found best to get sufficient numerical noise to instantiate a high-Q based oscillation. However, there are other means, albeit somewhat artificial as they can mask potential start-up issues, to induce oscillation. One method, which may or may not work based on your oscillator topology is to force an initial condition at one or more oscillator nodes that will result in some displacement current at the onset of the simulation. Analogous to this method is to use the DC operating point/state file from a prior transient simulation where the oscillator was near steady-state operation at the end of the simulation. Finally, there are many cases where the use of a pulse generator to create enough noise at the expected oscillator frequency is used to initiate oscillations.

My basic hypothesis as to why your observations concerning the clock to the veriloga module appears to impact the presence of oscillations is that this is inducing just enough numerical noise into oscillator nodes to instantiate oscillation in some cases. If you think you may have start-up related issues and want to overcome this behavior to study things other than oscillator start-up, you might also just reduce the Butterworth resistance in your resonator model. This will have the effect of increasing the open loop gain and reduce the amount of simulator noise to initiate large-signal oscillations.

I hope I've understood your question and, more importantly, this provides some food for thought David!

Shawn

Dear David,

David Mulvihill said:

But when I add the verilogA module in to the testbench, even if I keep the oscillator inputs connected to the same vpwl/vdc sources, the oscillation dies when enabled. 

David Mulvihill said:

Are there other settings to prevent this from happening? As you can imagine, setting maxstep to 1/500 of the oscillator period substantially increases simulation time.  I've tried changing reltol and abstol settings, but not surprisingly, it's not helping that much, can have negative effects and is slowing down the simulation far more than constraining the maxstep size does.

I can empathize with your observations David as I've spent a considerable time designing and simulating quartz resonator based devices! 

I will add that my experience has shown that forcing the maximum integration timestep to a fraction of the expected oscillator period combined with a conservative choice for simulator accuracy is the methodology I have found best to get sufficient numerical noise to instantiate a high-Q based oscillation. However, there are other means, albeit somewhat artificial as they can mask potential start-up issues, to induce oscillation. One method, which may or may not work based on your oscillator topology is to force an initial condition at one or more oscillator nodes that will result in some displacement current at the onset of the simulation. Analogous to this method is to use the DC operating point/state file from a prior transient simulation where the oscillator was near steady-state operation at the end of the simulation. Finally, there are many cases where the use of a pulse generator to create enough noise at the expected oscillator frequency is used to initiate oscillations.

My basic hypothesis as to why your observations concerning the clock to the veriloga module appears to impact the presence of oscillations is that this is inducing just enough numerical noise into oscillator nodes to instantiate oscillation in some cases. If you think you may have start-up related issues and want to overcome this behavior to study things other than oscillator start-up, you might also just reduce the Butterworth resistance in your resonator model. This will have the effect of increasing the open loop gain and reduce the amount of simulator noise to initiate large-signal oscillations.

I hope I've understood your question and, more importantly, this provides some food for thought David!

Shawn

Dear David,

After I wrote my response,  I had another thought that I've not tried but may work. Since the oscillator relies on numerical noise in a conventional transient simulation to initiate steady-state oscillation, suppose you enable transient noise at the beginning of your transient simulation with a noisefmax that exceeds the resonant frequency of your quartz resonator and then disable transient noise after some time period.

Presumably with the noisefmax exceeding your expected oscillation frequency, there will be some finite noise in the frequency range to initiate the buildup of oscillations. There will be a transient response whose time constant is related to the Q of your oscillator as a result of turning off transient noise, but hopefully its impact will not limit your oscillator settling time. If you've not enabled or disabled transient noise in a transient simulation, there is a Troubleshooting article at URL:

https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O0V000009MnubUAC&pageName=ArticleContent

Shawn

Hi Shawn, thank you for the replies and the sympathy. :-)

I do often use artificial testbench constructs or circuits to speed up getting energy in the resonator - my favorite is to use dynamic parameters to ramp up/down motional inductance / motional capacitance of the resonator, thus ramping up quality factor, to artificially and quickly get full oscillation.

In this case I let oscillation build naturally.  In this test I did:

• started with maxstep of 1/20 of the osc period.  I put in a delay in the vpulse source to the verilog-A module.
• let things fully settle out
• when settled, I started the vpulse source.  At the same time I used dynamic parameter to sweep maxstep settings

Even with large signal swing on the oscillator, the clock edge evaluation in the verilog-A is damping the oscillation. maxstep = 1/300 osc period maintains oscillation but with reduced amplitude.  1/3000 osc period has a small effect on amplitude but obviously runs very slowly. :-)

If this is just a fundamental simulator accuracy issue with verilog-A, I can re-write the code to use a slower clock period to reduce the effect, and use some hand-drawn std cell logic in the testbench for parts that need higher frequency.  But I was hoping there was some setting that I am missing. Thank you!

I'd strongly advise you to contact customer support - there's a lot of detail needed here to correctly diagnose what's going on, so I'm having to guess quite a bit - being able to share more info to customer support would eliminate a lot of that guesswork.

One idea I had was that the transitions (either on the clock source, or in any transitions in the Verilog-A) are causing the simulator to switch to the Euler method at each transition (because the derivatives are discontinuous otherwise and the local truncation error mechanism trying to look past the transition change doesn't make sense). This damps heavily, and whilst only for a single time step - if it's at enough time steps maybe it's enough to damp out the oscillation. It doesn't need to be connected to the oscillator for this to happen. It's not entirely obvious what you can do about this (other than maybe de-Qing the crystal model) - but this is why seeing the testcase would really help.

Regards,

Andrew

I also meant to say that I don't think there are any "fundamental simulator accuracy issue with verilog-A" issues - but again, better understanding of the interactions in the circuit would really help here.

Andrew

Thank you very much Andrew, I'll get in touch with customer support.

Figure 12 (expanded x-axis)

Dear David,

Please allow me to add two more comments regarding your observations and Andrew's comment.

1. For any high-Q oscillator simulations, I've always forced the integration method to gear2only to avoid the use of other integration algorithms.

2. Have you a small RC filter in series with each output of your verilogA block and in series with your vpulse input to the verilogA block? For example, set the RC filter to use a series resistor variable rs and parallel capacitor cs to ground with values of, say, rs = 50 and cs = 5p, to remove the sharp discontinuities in the verilogA outputs and vpulse as they transition from their logic values. As an example, figure 1 and 2 show the impact of using this filter on an ideal voltage output with a specified transition time of 100 ps.

Shawn

ShawnLogan said:

For any high-Q oscillator simulations, I've always forced the integration method to gear2only to avoid the use of other integration algorithms.

Shawn, that won't help. For a start, the gear2only and traponly are slight misnomers - I always thought they should be called gear2mostly and trapmostly (!), because at breakpoints (such as the start/end of a transition in a voltage source or Verilog-A transition) it will always switch to euler for that time step as it needs to revert to a first-order integration method as integrating across the discontinuity would be a challenge. Secondly, gear2only also introduces a small amount of numerical damping (much less than euler, but it's there nevertheless, and will be there all the time) and often is not the best choice for high-Q oscillators as it can tend to damp out oscillation. That doesn't mean that it won't work, just that it's more likely to lead to damping of oscillation.

ShawnLogan said:

Have you a small RC filter in series with each output of your verilogA block and in series with your vpulse input to the verilogA block? For example, set the RC filter to use a series resistor variable rs and parallel capacitor cs to ground with values of, say, rs = 50 and cs = 5p, to remove the sharp discontinuities in the verilogA outputs and vpulse as they transition from their logic values.

This is unlikely to help either, for two reasons:

1. The output of the voltage source is still in the matrix and needs to be solved for, and so the sharp transition is still present
2. The breakpoint generated by the voltage source will still trigger the use of euler method for the time steps at the beginning and end of the transition where the derivative is not continuous.

What might help is to use the edgetype parameter on the source, setting it to halfsine. This will mean that there's a smooth transition and the derivative at the output of the source is continuous too - if my memory is correct, this removes the breakpoint (well, it might be a soft breakpoint to try to force a timepoint, but I don't think it will trigger the reversion to euler method). Of course, this won't help if you then have transition statements in the Verilog-A.

One possibility might be to change the transitions in the Verilog-A to halfsine-like changes. I don't have an example of this, but similar logic is in this bsource implementation I wrote many years ago (almost 20 years ago!) as a prototype for what then became the edgetype=halfsine implementation in the sources:

//

inline subckt sinsq (a b)
parameters rise=1n fall=1n period=20n width=10n delay=1n v1=1 v2=5 pi=3.1415926535
sinsq (a b) bsource v=\
($time-floor($time/period)*period)<delay?v1:\
($time-floor($time/period)*period)<delay+rise?\
cos((($time-floor($time/period)*period)-delay-rise)*pi/rise)*(v2-v1)/2+(v1+v2)/2:\
($time-floor($time/period)*period)<delay+rise+width?v2:\
($time-floor($time/period)*period)<delay+rise+width+fall?\
cos((($time-floor($time/period)*period)-delay-rise-width)*pi/fall)*(v2-v1)/2+(v1+v2)/2:\
v1
ends sinsq

v1 (1 0) sinsq rise=2n fall=2n

tran tran stop=40n maxstep=0.01n

You'd need to convert this into equivalent Verilog-A syntax, of course.

Regards,

Andrew

Dear Andrew,

Thank you again for reading my comments and adding your insight! Please allow me two comments.

Andrew Beckett said:

For a start, the gear2only and traponly are slight misnomers - I always thought they should be called gear2mostly and trapmostly (!), because at breakpoints (such as the start/end of a transition in a voltage source or Verilog-A transition) it will always switch to euler for that time step

I understand this from the Cadence documentation. My understanding, rightly or wrongly, is that the choice of the "gear2only" algorithm will utilize gear2 as the dominant algorithm and to a greater extent than specifying "gear2".

I am also well aware of the numerical damping the algorithm provides. However, this is easily overcome by a sustaining amplifier and its resonator with a reasonably robust design. In fact, if the algorithm is responsible for damping out an oscillation, it is probably a very good clue the design is not sufficiently robust! With respect to David's problem, I would think it would help the convergence as the integration seems to be overly sensitive to clock transitions. My personal experience, and I will only speak for myself, is that "gear2only" has provided the most robust convergence simulation results.

Andrew Beckett said:

This is unlikely to help either, for two reasons:

1. The output of the voltage source is still in the matrix and needs to be solved for, and so the sharp transition is still present

Having written a numerical integration algorithm many years ago, it seems to me the difficulty in a numerical algorithm converging on an ideal source with a discontinuity driving a series resistor [1] and it driving an arbitrary load impedance is significant. I have not experienced any integration issues when an ideal source drives a purely resistive load whose resistance value is reasonable. This was the motivation for my suggestion to David.

If the Cadence algorithm reverts to a first-order integration algorithm in this case, I am surprised, but will accept your answer !

Shawn

[1] i.e., a state voltage is not involved

ShawnLogan said:

I understand this from the Cadence documentation. My understanding, rightly or wrongly, is that the choice of the "gear2only" algorithm will utilize gear2 as the dominant algorithm and to a greater extent than specifying "gear2".

This is covered in A.3.3.7 (page 352) of Ken Kundert's A Designer's Guide to SPICE and Spectre.

ShawnLogan said:

I am also well aware of the numerical damping the algorithm provides. However, this is easily overcome by a sustaining amplifier and its resonator with a reasonably robust design.

Of course, but given that the oscillation was already being attenuated, gear2only will only make that worse. In general, gear2only often gives the best bang for the buck, but trapezoidal generally will give the best accuracy - but sometimes the presence of trapzoidal ringing can cause a bigger problem - so there's always a tradeoff.

ShawnLogan said:

If the Cadence algorithm reverts to a first-order integration algorithm in this case, I am surprised, but will accept your answer !

This is covered in section 4.2.1 and 4.2.2 of Ken's' book (pages 131 onwards).

Andrew