Re: Oscillator Simulation

On Tue, 13 Sep 2016 14:37:52 +0200
Felix Salfelder <[email protected]> wrote:
> On Tue, Sep 13, 2016 at 10:03:51PM +1000, Richard Gipps wrote:
> > VCC 10 0 PULSE(0 8)
> 
> there seems to be a problem with the time zero value of that pulse
> try "VCC 10 0 PULSE(0 8 1p)" instead. maybe "(0 8 0 1p)".
> (not sure if this is a bug or a feature. spice implements some guessing
> around zero-time transitions...)

It's a bug ..  In two places in bm_pulse.cc EVAL_BM_PULSE::tr_eval, ">="
should be ">".  (lines "falling" and "rising")

It is intended to mimic the Spice pulse, therefore it should work the
way Spice does.

But that's not "The Problem" here.  It does explain why gnucap and
spice give a different starting point.

There is another hidden issue here, something I have been working on.
As originally stated, rise=fall=delay=0, there is nothing in the
circuit to hint at what time stepping to start with, so the automated
step control would miss the oscillation.  In the original, the
requested step of 1ps was a hint, but otherwise with what Felix
suggested, it would have skipped by the oscillation.  You might call
this a "bug" but most other simulators are worse.

By giving a finite rise time, the simulator now has some basis to
figure out time stepping and can go from there.  You just need
something, somewhere, that somehow requests a step size less then the
expected period of the oscillator.

> > .OP
> 
> the tran command will care of that.

... when time starts at zero.
When time does not start at zero, it most likely will continue from the
previous run.  This is a difference from Spice (a feature).  Spice
always starts at zero, but may hide the time leading up to the time you
ask for.

> there should be no difference if you
> leave it out.

Putting it in makes it happen twice.  Use OP when you want more data,
or before an AC analysis.



> 
> > .TRAN 1p {stop_time} {start_print} 1p
> > .PRINT TRAN V(1)

See my other email about the "1p" step size.

> in gnucap, the .print command actually attaches probes to the circuit.
> after the simulation it's too late. but i think, generally, you can run
> a simulation, attach probes, then continue.

Yes .. I do it all the time.

My comments following explain what Felix did, and why.

> maybe you want to try this instead
> 
> .TRAN 0 {start_print} {start_print/10}

Start at zero, up to {start_print} with minimal output, only 10 steps
will be printed.  Gnucap will determine what internal step size is
needed.

> .print tran v(nodes) v(VCC)

adds the probes for what you want to see.

> .TRAN {stop_time} trace=a

This line continues the transient analysis from where the previous one
ended.  "trace=a" (I prefer "trace all") shows all time steps, which
are often unevenly spaced.


You didn't say anything about accuracy, but I will ...  The default
tolerances are often not good enough for detailed work on oscillators.
It is tempting to manually specify smaller steps, but that is not a
good idea.  Tighten the tolerances, especially "trtol".  I like trtol=1
for this.  It will run slower, but that's ok if it provides the
accuracy you need.

Another thing that will improve accuracy is to connect the output of
the oscillator to the input of a switch, (S device) with a switch
voltage at the middle of the oscillator swing.  This creates a "cross
event" which will let you accurately measure the period and frequency
of the oscillator, to the specified tolerance.

If you do this, it should be accurate enough for the fourier command to
measure distortion.

Check out the "measure" command for measuring frequency, etc.