(Reference#7231113) Phase-Locked Loop settling time

[Euler's_Identity]

(Reference#7231113) Phase-Locked Loop settling time

Date: Feb 23, 2009 6:54 AM

Thank you for contacting National Instruments!  This message is an
automatic response from our e-mail support system to let you know that we
received your support question.

Our e-mail support hours are from 8:00 AM to 6:00 PM United States Central
Time, Monday through Friday.  An Applications Engineer will typically
respond to your support question within 12 business hours, barring
holidays.  For a list of holidays for the NI US offices, please check
http://www.ni.com/support/holiday.htm.

--> Next time, consider posting your question to the NI Discussion Forums for
--> immediate access to engineers and developers around the world.  NI
--> Applications Engineers monitor the forums to ensure all support questions
--> are answered.  To access the discussion forums, please visit
--> http://forums.ni.com.

If you resolve your issue before receiving a response from a support
engineer, please inform us by replying to this message.

Thank You,

National Instruments Technical Support Team


----------------------------------------
Problem Description :

I'm trying to determine whether or not my PLL synthesizer is finally
settling
to the desired output frequency.  To do this I need to see the response of
my
circuit after a simulation-wise long time period.  Thus far, after hours of

waiting, the maximum time period of simulation has been about 70ms -- I
just
left the thing running overnight (hours!).

What can I do aside from wait hours and hours?  I'm interested the response
0.5
seconds to 1.5 seconds after start up.  How can I see this?

I'm thinking this is a general question that you can just answer, but if
you
need the circuit I've included it.

Note: As Multisim did not have some of the models I needed, I'm using
subcircuits as models.  Any help you can give for how I might convert the
subcircuits to easier-used models I'd also appreciate, as right now I'm
just
using the "paste as subcircuit" option.

P.S. Feel free to call me at [number removed] if you'd prefer one-on-one
conversation.

NI Software :  Multisim, Ultiboard  version 10.1
NI Hardware :  Select one if your issue is related to hardware device
Driver Version :
OS :  Windows XP
Customer Information :

[contact info removed]

Based on the section I've "-->"'d above, now I'm trying here instead.  It doesn't matter to me how I get it as long as I get an answer.

[Euler's_Identity]

Note that I saw

------ begin paste -----

Setting Transient Analysis Parameters

Setting Transient Analysis Parameters for Normal Use

The default settings are appropriate for normal use, providing the transient response of the selected output variables starting at time 0 seconds and stopping after 1 ms (0.001). You can, if you wish:

change the start time by entering a value greater than or equal to 0 and less than the End time in the Start time (TSTART) field
change the end time by entering a value greater than the Start time in the End time (TSTOP) field.

------ end paste ------

in the help.

I set up the "set to zero" option, a start time of 0.5s and a stop time of 0.52s, I selected the variables I wanted to view, and then I ran transient analysis.  How long should I wait before I conclude that transient analysis isn't running when it says it is? (The progress bars in the bottom right are ticking away, but the simulation clock is stuck at 0.000s and has been stuck at 0.000s.)

For the fun of it, I'm going to leave it running.  Maybe I'll get lucky and several days from now I'll get my answer (7 hours = 30ms(sim)), perhaps in time for my parts to arrive.  (The original idea was to order the important parts and then simulate to fine tune the design so that when my parts arrive I'll be set to build the prototype.  So's for that idea, at least to this point.)

What is the point of setting a start and stop time if it still takes just as long to get the results?  I'm thinking that running a transient analysis instead of using the scope (the way I usually go) is supposed to save time, as there's no need to update anything but the grapher window.  But holy shnykies!...  At a rate of 7 hours=30ms(sim), I'll be able to find out if my synthesizer is outputting the correct frequency in

[7 hours/30ms(sim)](1 day/24 hours)[1s(sim)] = 9.7 days!

So I'm figuring, assuming the computer doesn't stop for some reason, by next Wednesday my PLL should be settled.  Please tell me there is a better way than this, because at this point I might as well continue doing the math, at least as I see it.  (The idea was to do the math enough to get some equations for Excel, and then use Excel to generate circuit parameters, and then use Multisim to test the circuit a little before prototyping.  It seems I've miscalculated.)

[Euler's_Identity]

Perhaps there is some way of knowing where the simulation is, time-wise, before it has finished?  It'd be like that game show where the guy gambles whether he wants what's in the briefcase or not.  Do I want the results now, or do I want to gamble that the computer will keep running the simulation?  [insert "I'm a Little Teapot" melody here]

I've noticed that after some of my simulations have run for a bit, it takes quite a while for Multisim to shut down.  I can just imagine what this one's going to be like.

It reminds one of Deep Thought and how after millions of years it returns with the answer to the question of life, the universe and everything.

There has got to be a better way...

6x9=42...

[Euler's_Identity]

Here's a partial screenshot.

[Euler's_Identity]

All humor aside, this may be the only way to get the simulation result.  This is after all a frequency synthesizer, so it is rather complex.  It really may need 9.7 days to get to one second of simulation.  Hence, perhaps the best solution is the mathematical one.

I think, as a compromise, I'll stop the transient analysis and restart it to experiment a little with analysis-time with the analysis vs the scope.  If it turns out the scope is only slightly slower, at least I'll have a clue about how far the simulation has gone.

[Euler's_Identity]

Well I had to go back to the scope output, because I couldn't seem to get the transient analysis past 811us for some reason I haven't figured out.  How does the scope's trace differ from the transient analysis?  I do note that the scope's trace does keep restarting every about 700us<t<800us, seemingly generating a new batch of data with each restart -- I can't scroll back like I might with the grapher window.

If I could only tell somehow if the loop filter's output voltage is exhibiting a damped exponential character or not, then I could determine if there was convergence towards a particular value or not.  I saw the VCO control voltage ramp up from 0 (due to the "set to zero" setting), but I can't tell if it's settling.  The output shows it could settle (days from now) somewhere between 2.6 and 2.8 volts (supply is 5v, and 4 MHz is near the middle of the VCO range.)  The output also shows the output frequency of the feedback divider is varying a lot (80 counts in 20us (4 MHz) vs 80 counts in 260us (307 KHz)), which doesn't make sense considering I've set up an ideal (linear) VCO conversion gain.  In contrast, the VCO output frequency (what's feeding the divider) shows no where near this kind of frequency variation; rather, it's showing, using the other scope, negligible period variation outside of 225ns (4.4 MHz.)  My target frequency is 4.096 Mhz (period: 244ns), and given the resolution and the fact that I can only set up the markers and leave them while watching the clock pulses wiz by, I'd say I'm pretty close.  Hence, my conclusion to this point is that my circuit seems to be working but that Multisim v10.1, assuming the majority of the evidence is correct, has lost data with respect to the output of the divider for some reason.  But hey, in my opinion, despite the cumbersome nature of all this, Multisim is still quite rocking!  This thing is a frequency synthesizer, meaning the math involved is quite complex, especially since I'm mixing an analog analysis (the control voltage) with a digital analysis (the output of the divider) on the same scope -- it wouldn't surprise me a bit to find I've maxed out Multisim's abilities with this thing, why it just might BE losing data.  This program is great. ...but MAN is this taking forever!  My fan rarely runs on my machine, but it seems to have been cycling on and off all night long -- evidence that there's been some serious number crunching going on.  But yet Multisim keeps chugging along. 🙂

[Euler's_Identity]

Here's a screen capture.

Cheers!

[Euler's_Identity]

In explanation,

The upper scope is the VCO control voltage (upper trace) and the output of the divider (lower trace, partially obscured by the second scope).  Notice the gaps?

The lower scope is the reference oscillator (upper trace) and the VCO ouptut (lower trace.)  Notice the markers?

The voltmeter is the VCO control voltage coming from the loop filter.

The upper freq counter is supposed to be the frequency after the divider.  Notice how it's blank, can't come up with an answer?

The lower freq counter is the VCO output.

As you can see, the simulation hasn't been running for long, sim time, but it's been over about seven hours of actual run time now.

Personally, I'd call this simulation a benchmark, assuming I could even get it to run in another simulator.  ...which I do plan to try. 😉

By the way, I'd upload the synthesizer circuit to this forum so that others could try it out (and, of course, try out Multisim), but I don't, technically, have permission to do so from my company.  (I've signed a non-disclosure agreement for proprietary docs.)  So much I'd like to get other engineers in on solving this sim-time problem, get other meatier machines on it.  But I can't.  So currently only myself, my company, and NI Multisim (via "ask an engineer") have the circuit. 😞

The good news is the heart of the thing, the PLL itself, is available in the forum, because I uploaded it (as a circuit, not a subcircuit like I'm using here) over a year ago.  Bear in mind though that the VCO will need to be adjusted to your frequency range.  ...by the way, I'm still looking for a suitable alternative to the subcircuit -- I want a component model instead.

[yyao]

That looks like some interesting simulation that you are performing.

I have read before that traditional SPICE simulators such as Multisim have trouble performing timing circuits such as VCOs and PLLs. This was explained to be the result of the huge time step differences required to make the simulation efficient. I remember seeing in the back of a course textbook the author's personal homebrewed method of simulating such circuits written in C. The book is Analog Integrated Circuit Design written by Johns and Martin and published by Wiley. You can find it on Amazon here. The example was given close to the end of the book. I haven't studied it myself, but given what you have said, I think it would be of use to you.

[Euler's_Identity]

As it is easier for me to respond/communicate in this manner, here goes...

------- begin paste from "ask an engineer" response ------

The only thing you can really do about the simulation speed is to change
TMAX under Simulate>>Interactive Simulation settings, the larger the Tmax
value the less restrictive you are with the simulation and it can take
bigger time interval if it is necessary.  In your circuit, you have a lot
of instrument and this can also slow the simulation down, just put what you
need on the schematic.  You used a 74193 in your circuit and this component
is available in Multisim, I think if you replace your subcircuit with the
component in the attached file, it should increase your simulation speed.

--------- end paste ------

As I understand it, TMAX is the maximum time interval between iterations.  In other words, if there is convergence within the TMAX interval, then the solution is taken and the simulator advances to the next iteration.  If there isn't convergence, then the time interval is reduced and the iteration rerun.  Correct?

In my simulation, every instrument serves a purpose.  None can be discarded.

The reason I used my subcircuit for the 74hc193's is because, as I saw it, I had to create my 74hc193 subcircuit, because Multisim's model doesn't respond correctly enough.  (Of course I would have preferred to use Multisim's model for such a readily used device as the 74hc193, just the same way I'd have preferred to use Multisim's model for the 74hc4046.  I do not deliberately make more work for myself -- I don't seek out ways to make my life more difficult.  Rather, Multisim fell short on both counts, and I adapted as I saw possible.)  For that matter, even if the hc193 part responded correctly, with respect to BO', I still do not trust that it is an hc193.  It took time to create that subcircuit, but it had to be done.  And, as another point, the reason I had to use the PLL subcircuit is, once again, Multisim's PLL wasn't correct, and Multisim doesn't even have the 4046, an industry standard.

That said, the simulation is currently at 316ms.  I saved what's supposed to be the results at roughly 300ms.  However, to my surprise, instead of getting a Multisim-readable data file with a unique name, I now have a new name for my simulating circuit.  I'm puzzled.  As I understood it, the results of all simulations, with respect to the variables chosen (I picked points to monitor the voltage via the oscilloscopes), were recorded.  Yet, I pulled up the grapher, and it appears that there are only two tabs, where each tab only shows the current scope view.  Yet, when I saved the data thus far (I thought), I did get at least one positive response in that Multisim told me that the amount of data exceeded the chosen 1MB size and that 4.?MB would be saved instead.  Of course I saved it.  But I'm rather confused about just what was saved.  I'm thinking, based on the evidence, that all that was saved was one scope trace of each scope.  I'm now preparing myself to hear that, even though this simulation has been running for many many hours, over days, the only data I saved was one measily scope trace, which, based on the evidence of a scope trace that doesn't finish but stops and retraces after about 7.5 divisions with a 100us/Div setting (the VCO control voltage and feedback divider output scope, the upper one), is less than 800us.

This is interesting because, for some reason, even though when I ran my original (way back, time-wise, in this thread) transient analysis and asked for a transient analysis up to 1ms (this is when I experimented with making shorter transient analyses and finally picked the one the manual said should work), I couldn't get the thing any further than about 811us.  Yeah, no matter what end time I chose, I never got past this 811us barrier.  I even increased the number of data points thinking that was the indirect cause, but still I couldn't get longer than 811us.  For my synthesizer design, 811us is useless, not even a drop in the bucket.

Hence, as I see things right now, what I want to know, despite my work thus far, will only be had days from now, when I finally see that one last <811us scope trace that shows me my control voltage has finally settled.  I hope that isn't the case, but based on the evidence thus far, I'm preparing myself for that result. ...there's alchohol readily available if the power should go out before I get there.

Please tell me I'm wrong.  Please tell me that all this data that's been generated isn't just falling off into the great bit bucket in the sky.  Please tell me that I just made a mistake, that I didn't choose to save the data properly before I started the simulation, that I missed some crucial detail, and that that is the reason why, to this point, I only have <811us of data to show for it.  Please tell me that.  But whatever you tell me, please don't lie to me.

At this point, at<350ms of sim time, if I can save the data I need to start this thing over, now, not days from now.  (I'm wanting one second and better.)  My VCO control voltage looks like it's settling to closer to 2.5v than 2.7v now.  Where it will go, whether it settles, is unknown.  Now is the time to tell me, not later.  I've scoured the manual (in what I saw to be the relevant areas -- it's after all 800+ pages total you know), and I have yet to find a definite answer to my questions.  I gave you my phone number, but you haven't called me.  I even called domestic and then Canada, twice, finally left a message on some voicemail somewhere.  In total, I've spent many hours trying to get answers, here, the simulator, and the phone.  The most I've received is one post (as good intentioned as it was -- thanks yyao) and one email, an email which clearly shows me there is a lack of understanding of my needs.

Hence, without any better evidence to this point, I can only see the way clear to let the simulation run and every so often save the "data", creating a new name for my simulating circuit, and hopefully, based on the <811us fragments of data, interpolate what did what when later, days from now.  ...after my parts have arrived. ...which largely defeats the purpose of simulation. ...which does not make me a happy camper.

I can understand that it'll take a long time to run -- it'd have been nice to find a means to reduce the time, but it is what it is.  What I can't understand is designing Multisim such that the user cannot save the data requested over that long time period.  That's what large capacity hard drives are for!  You process the math, store the data for the next iteration, pass the current data to the hard drive, and then continue to the next iteration.  By the looks of things, that is not what is happeneing with respect to this simulation that is underway.  The idea is that, even if the simulation can't continue for some reason (for example, the bottom falls out of the dollar, all power is rationed nationwide, the government declares a 1933ish "bank holiday," a national id system is instituted through martial law to divide the "wealth" etc etc), the data gathered thus far can be analyzed in order to predict whether the synthesizer's loop filter would likely cause the VCO control voltage to finally settle thus producing a relatively steady output frequency from the synthesizer.  That's the idea.  I can't stress it enough. Now is the time to tell me whether or not I should restart this simulation.  I want that scope data!

...42...