(Reference#7231113) Phase-Locked Loop settling time

[Euler's_Identity]

A funny thing happened on the way to the forum.

I had the simulation minimized as I was doing other things earlier, so I returned to the computer and woke my monitor from sleep/off.  Of course I had to check to where things stood with regard to the simulation, so I clicked to bring up the simulation again and was met by the simulation running, based on the evidence of the green progress bar, but with an error window in the center of the screen.  I've attached the screen capture -- it's an odd error.  However, it is not bad news in that, and I was surprised at this, I finally clicked "Ok," got another one, but then the simulation continued on.  We're now at 445ms.

I'm disappointed to see no response from NI Multisim with regards to my question just prior.  I will add there though and say, as I'm out of time, that the last save I did, a couple hours ago, took a considerable amount of time.  The question is, was it saving a lot of data, or is there a memory leak and saving is taking longer now?  I'll eventually learn the answer.  Windows isn't great on memory and never has been.

Oh, and the loop hasn't settled yet.

[Euler's_Identity]

For my latest update, I have good news and bad news.

Good news:

1.  I have a great benchmark here in this synthesizer design.

2.  Multisim has what it needs, as at the beginning of all this I sent NI Multisim the synthesizer design via "ask an engineer," and a key piece is minimizing and maximizing a running simulation.

3.  If the data generated by Multisim was indeed saved (although I'm suspecting I actually have little at this point, reflecting upon what was hypothesized earlier), I'll have enough to be able to determine, mathematically, if my loop ever settled.

Bad news:

1.  Multisim v10.the latest rev as of December '08 has a memory leak, because I found out this morning what it looks like when my machine runs out of memory.

It was so bad that I couldn't even shut the machine down via Windows much less get a last screen capture.  Multisim had frozen in its tracks.  The progress bar was locked green.  The display looked perfect, and the scopes were mid-trace in the settings displayed in that last screen capture.  The sim time had advanced to, that I know, 440ms<t<460ms, but I'm thinking it was 455ms.  I had this one puny and very sad window in the center of the screen that said "Out of memory!" on top of an excellent simulation display.  I tried to jump to Paint Shop Pro, which was minimized, what I've been using to get these area captures, and PSP ran fine, at least enough to set up my hotkeys to capture an area. But, as Multisim, of course, was minimized by this action, I was caught mid transition between PSP and Multisim, and Multisim could never regenerate its windows.  It looked bad, the worst I've ever seen in all my "computing" days.

It tried to regenerate the VCO control voltage trace and the divider return (remember that missing pulses thing?!) signal, but it only got out a smidgen.  The rest of the display was, as best I can describe it, a sea of blank windows.  There were a few sparse bits of text data readily seen amongst the empty windows.  The Paint Shop Pro identifier at the top of the screen never went away.  Multisim was frozen, locked up as tight as a drum mid-transition between PSP and itself.

Now it's all about finding out what data I got and what I can do with it. 

National Instruments, despite all I've been through these last few days with respect to this simulation, I still think Multisim is a dynamite program, and I want to renew my service contract yet again.  Even if this memory leak is still present in the next revision, if it is no worse than what I have, I still want the next revision.  In my opinion, Multisim is a new paradigm in circuit simulation tools.  From my experiences, Multisim is making headway in the engineering realm -- it just needs a little more time; perhaps what's necessary is only to solve this memory leak.  It was not my intention to crash Multisim, but it seems my PLL synthesizer has indeed done just that.  I'll do my best to get it to run on another "more professional" (Multism rocks!) simulation tool and get you the results as soon as I can, despite the learning curve such an endeavor will entail.  I want and wish the best for National Instruments' Multisim, and I will do what I can to help you fix this program, even if it means tackling the learning curve to port this PLL synthesizer to that God-awful SPICE monstrosity, where I don't even remember who bought them last.  I know a value when I see it, and Multisim, in my opinion, despite its querks, is valuable. You have my number, so please give me a call so that I may renew my service contract. 😉

[Euler's_Identity]

Well, I've figured out some more.

I've been curious about how it seemed that Multisim lost data returning from the feedback divider.  (See one of the prior screen captures and look for the missing pulses.)  So I decided to decode when the hc193 was at its minimum count.  The idea was to produce pulses at the same time that the BO' combination logic would be doing its thing, pulses that should coincide with the BO' combination logic pulses.  I wanted to see what was causing the pulses to disappear, and when they'd disappear on the one trace, if things were correct (meaning my circuit was the fault, not Multisim), they should also disappear on the other. 

Here's what I found.  I found that the pulses never disappeared!  Likewise, I found that my VCO control voltage never exhibited that steady climb character seen during the time span of the missing pulses either!  Investigating this oddity further, I determined that, to cut a long story short,

1. the way the scope was attached to the circuit was the cause, and

2. memory was being gobbled up (I watched Task Manager's display) during the time span of the missing pulses.

That was what was puzzling me about this.  I'd thoroughly tested my hc193 subcircuit, so I was pretty confident it was functiong correctly, but yet the BO' combination logic feeding its signal to the phase comparison input of the PLL was stuck low for a totally unreasonable length of time; this in turn caused the phase detector (within the PLL subcircuit) to create a tremendous error voltage causing the VCO control voltage to rise, which finally lenthened the settling time to a settling time that'd be, then, long after I'd run out of memory.  Did you catch all that?  In other words, Multisim, due to the way the scope was attached, caused the simulated circuit to produce an error that the simulated circuit, in turn, considered part of the simulation and, therefore, reacted to.

The way the scope was attached was one channel went to the PLL reference, and the other channel went to the VCO output, so I could see the phases locked.  Somehow that combination creates the missing pulses error, causes Multisim to lose the BO' combination logic output data.  That combination logic output must be there, or my circuit will not function correctly. Period.  An easy way to kill a functiong PLL is to ground the phase comparator input, give the phase detector logic an incorrect input. 

Next I'm going to try my circuit again but not use that scope combination this time.  I'm wondering if I'll finally get a lock and without running out of memory this time also.  ...but it'll have to wait for the moment as I gotta run.

The saga continues...

[Euler's_Identity · Accepted solution]

Yep, that was it in that Multisim caused the problem. However, the problem/cause isn't as simple as I'd originally thought, for I modified my original circuit by removing the offending scope, and I still got data loss.  To tell ya the truth, I just don't know about this.  One thing I've thought of which might have a bearing is I'm generating the equivalent of the BO' combination logic's output signal and feeding it to the scope.  Maybe this is causing the software to not create the error somehow?  Whatever is the cause the good news is I did get a lock and without being at any risk of running out of memory -- lock was in under an hour.  I have decided though that I will increase my memory.  I like the long time span option, but my memory appears to be a little small for it.

Finally, the output VCO frequency isn't as stable as I want due to a roughly 80mv ripple.  Therefore, I'm going to try another loop filter, so it's back to the math.