5
\$\begingroup\$

I simulate a system of two mutually delay-coupled electronic clocks (DPLLs - digital phase-locked loops). This worked well and also in reasonable time so far. However, moving into a particular regime of the parameter space of the individual DPLLs, i.e., very low cut-off frequencies of the loop filters (fc=14Hz) compared to the free-running frequency of about 1kHz for the LTC6900 VCOs at a high coupling strengths causes problems. The transient simulation runs fast for about 100ms and then suddenly stalls with convergence problems of the solver (excerpt, full log-file below):

Heightened Def Con from 2.31358e-012 ++++++++++++to 2.3174e-012

Heightened Def Con from 0.0100466 to 0.0100466

I tried different solvers and limits, however I could not solve the problem.

This is the state at which the simulation stalls: enter image description here

This is the schematic I am simulating

enter image description here

This is a link to the netlist: link to netlist (dropbox) This is a link to the spice-log file: link to spice-log (dropbox)

Specifically my questions are: What besides changing the solver parameters can I do to solve the problem? How can I find out more easily on which calculation the solver gets stuck? Did I miss something in the schematic that could cause the stalling?

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Plenty of "cheats" available! Have you tried the Alternative solver? Injecting 1 mohm resistors in critical nodes? \$\endgroup\$
    – winny
    Commented Oct 5, 2018 at 12:41
  • 1
    \$\begingroup\$ I use the 'alternate' solver and the 'modified trap' integration method. How do I determine which are the critical nodes? \$\endgroup\$
    – cuichi
    Commented Oct 5, 2018 at 13:05
  • 3
    \$\begingroup\$ @cuichi nodes with very high rates of change can cause trouble (any switch turning on at that time?). Sometimes adding a small capacitor (pFs) to a node also helps. \$\endgroup\$
    – Arsenal
    Commented Oct 5, 2018 at 13:33
  • 2
    \$\begingroup\$ On top of what @Arsenal said, if you see any node jump up to MV range for ns or lower, a Mohm resistor to ground usually helps. In general, try to "bootstrap" yourself using ideal components first, like your OP, and then change gradually to real models. This way you can find where the problem lies. \$\endgroup\$
    – winny
    Commented Oct 5, 2018 at 13:39
  • 1
    \$\begingroup\$ Also try setting eeeever so slightly different delay times for the gates. For example Td=2n for A1 and Td=2.01n for A2. Maybe also Td=1.99n for one of the XOR games. BTW, you can eliminate Rmeas and C1 and set Rout and Cout inside the gate. There is no need to ground the gates since their 8th pin (the ground pin) is internally connected to 0 node (ground) unless otherwise specified. It's not a big deal, but it eliminates a bit the clutter. Also, try adding Rser and/or Cpar to the supplies, something like 1m, both. \$\endgroup\$
    – a concerned citizen
    Commented Oct 6, 2018 at 7:28

1 Answer 1

Reset to default
2
\$\begingroup\$

Many thanks towards all the people who contributed their comments, thank you @winny, @Arsenal, and @a concerned citizen!

The simulation runs and does not stall anymore after making these changes:

  1. added .option cshunt=1e-15 reltol=0.003 abstol=1e-10 gmin=1e-10, see LTwiki
  2. making XOR, d-flip-flop, and delays sightly heterogeneous

Before I had only made changes to reltol and abstol which did not suffice.

enter image description here enter image description here

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Have you tried without the .option part? Only the delays and, if needed, add a small tau=X to the gates, e.g. 1n. That should make the rising/falling edges smooth and convergence friendly. Do note, however, that it can only be either Rout/Cout, or tau, or trise/tfall at one time. Rout/Cout is just tau, but with control over Rout/Cout (otherwise Rout=1), and trise/tfall will make the edges straight (trapezoidal), rising or falling. \$\endgroup\$
    – a concerned citizen
    Commented Oct 11, 2018 at 6:53
  • 1
    \$\begingroup\$ @aconcernedcitizen I did try it with only using the heterogeneity, however that did not suffice. Also I have to admit that I am not sure that I introduced what you proposed. Do you mean Rout DIVIDED BY Cout with Rout/Cout, or do just Rout OR Cout. \$\endgroup\$
    – cuichi
    Commented Oct 11, 2018 at 10:00
  • 1
    \$\begingroup\$ I meant them as two terms (poorly written), Rout and Cout. Since you don't have output loading that should matter, it's safe to use tau (time constant), instead. That considers Rout=1 and Cout=tau/Rout=tau. \$\endgroup\$
    – a concerned citizen
    Commented Oct 11, 2018 at 14:06
  • 1
    \$\begingroup\$ I only have delays assigned to the XOR-operations, the d-flip-flops and of course the feedback and coupling connections. The operational amplifiers have no delay assigned. I hope that answers the question. \$\endgroup\$
    – cuichi
    Commented Oct 15, 2018 at 17:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.