The Designer's Guide Community
Forum
Welcome, Guest. Please Login or Register. Please follow the Forum guidelines.
Aug 25th, 2024, 9:16am
Pages: 1
Send Topic Print
calculation simulation time of initial transient (Read 8884 times)
Paul Geraedts
Community Member
***
Offline

GIGO

Posts: 60
Enschede, Netherlands
calculation simulation time of initial transient
Sep 20th, 2006, 8:23am
 
Hi all,

Let me start by summarizing what I know from the manual about this calculation before asking my question.


                A          B          C          D
           <--------> <--------> <--------> <-------->
|----------|----------|----------|----------|----------|
0        tstart     tonset     tinit      tstop

           <------------------------------> <-------->
                  initial transient             PSS


In which A is the time until all the independent sources excite the circuit in a periodic fashion. B is equal to the value of
'tstab', as set by the user, and C depends on the nature of the PSS: autonomous or forced. In forced PSS, it is equal to the
value of 'period' (the period of steady-state). In autonomous PSS, it is equal to 4 times the value of 'period' (the initial
guess of the period of steady-state). D is of course equal to (the current estimate of) the period of steady-state.

This clear definition of the simulation time of the initial transient allows me to calculate 'tstab' such, that the PSS
starts at a point in time where most of the initial transients have dissipated and where the state of the circuit is only
slowly varying. By doing so, PSS needs less iterations to converge which speeds up the overall simulation drastically.


Now my question. Why is Spectre not behaving as such? I mean, the actual calculation of the simulation time of the initial
transient strikes me far more random. In case of convergence problems, as a work-around, I set 'saveinit' to yes, look at the
signals during the initial transient and change 'tstab' accordingly. This costs more time though.

But it is not only occurring at an initial PSS. Even more striking is attached example (see file).

It was the result of the last analysis of a cascade of three PSS analyses on a rather stiff relaxation oscillator (I reused
the final state of the circuit at every subsequent analysis). I choose the cascade to overcome initial convergence problems
(the accuracy parameters were first set rather loose and were increasingly set tighter). After the third analysis the
accuracy of the obtained PSS was sufficient for the subsequent MIC refinement to converge.

The notice about the detected onset of periodicity (A in the above summary) is just wrong (after t=2*period, all the sources
excite my circuit in a periodic fashion)! I set 'tstab' (B in the above summary) to 0, so C is 2 times the estimated
period of steady-state (which is less than 4 by the way :). Why? Most of the initial transients have been dissipated by now.
As Spectre doesn't calculate a new estimate of the period of steady-state (as result the first 2 reported convergence norms
are equal: 150), the initial transient seems to do nothing useful! Furthermore, I'm only partly able to control the accuracy
parameters of the initial transient part (i.e. 'relref'). So in such situations, the initial transient is a bit of a pain
(don't forget: it takes up about half of the total simulation time)!


To summarize. In general, I would like to be able calculate the appropriate value for 'tstab' in advance. More specific,
when I set an initial condition file and leave 'tstab' at default (=0), I think both A and C should be zero (as long as the
initial condition file describes a state later than (tonset+C) (see the above summary), that is). So, no *initial*
transient before the PSS in such a situation (would be a contradiction in itself :).

Sorry for the long post, but I think it can save people a lot of simulation time when the whole thing is implemented
properly.

Kind regards,

Paul

P.S. I'm using IC5141USR2 together with MMSIM60USR1.
Back to top
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2386
Silicon Valley
Re: calculation simulation time of initial transie
Reply #1 - Sep 20th, 2006, 9:07am
 
Why does Spectre think V5 does not reach periodic behavior until after 12us? Can you post the portion of the netlist that contains V5?

-Ken
Back to top
 
 
View Profile WWW   IP Logged
Paul Geraedts
Community Member
***
Offline

GIGO

Posts: 60
Enschede, Netherlands
Re: calculation simulation time of initial transie
Reply #2 - Sep 20th, 2006, 9:38am
 
Hi Ken,

Here it is:

Quote:
V5 (_net1 0) vsource type=pulse val0=1.2 val1=0 delay=init rise=1p fall=1p


The parameter 'init' is set to zero during this simulation. V5 is the source that initializes the digital block.

t_onset seems equal to t_start + period (this was also the case in the second of the cascaded PSS analyses).

Could it be that A is rounded to the next multiple of 'period'? So that the 1ps fall time is rounded to 'period' (A=period)?

Thanks Ken!
Back to top
 
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2386
Silicon Valley
Re: calculation simulation time of initial transie
Reply #3 - Sep 20th, 2006, 10:15am
 
You did not specify a period, meaning that the pulse source produces a step, meaning that it reaches the onset of stability after delay+rise = 1ps. This is a bug in the simulator and it should be reported to Cadence.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
Andrew Beckett
Senior Fellow
******
Offline

Life, don't talk to
me about Life...

Posts: 1742
Bracknell, UK
Re: calculation simulation time of initial transie
Reply #4 - Sep 20th, 2006, 11:24am
 
Omitting the period should not cause a problem - it doesn't seem to in my experience. But the message does look a little suspicious. It's rather hard to tell though, since you've only given a subset of the output log (you've omitted the first part of the pss), and the netlist would make life easier to see.

I've not seen this kind of problem before. I agree with Ken, you should report it to Cadence.

Andrew.
Back to top
 
 
View Profile WWW   IP Logged
Paul Geraedts
Community Member
***
Offline

GIGO

Posts: 60
Enschede, Netherlands
Re: calculation simulation time of initial transie
Reply #5 - Sep 20th, 2006, 2:05pm
 
Ken and Andrew, thank you both for your time!

A bug, that was my initial guess as well. Andrew, I've attached the complete log now (I don't think it does contain any
missing information though). I would prefer not to attach the netlist, because of a possible publication. Our university
receives the Cadence software through the Europractice program. Our technician told me that this makes contacting Cadence
a rather inefficient and time consuming process.

Though I don't think you really need the netlist. In my experience it is normal behaviour (observable in all of my 3
subsequent analyses). A basic autonomous PSS analysis of a random oscillator which is started by a pulse source would
probably be sufficient to display the same behaviour. As far as I observed, the method of calculation as put in the manual
and the real method are different. In a sense, it is about the elegant difference between a bug and a feature of course : ).
I don't mind which one it is, but I would like to know the details about the real method.

But what about the other part of my original post? Wouldn't you both agree that the initial condition file I set, should
result in A=B=C=0 (as tstab=0), meaning the 'initial' transient should be omitted?

An option to disable the initial transient would be sufficient as well, by the way.

Paul
Back to top
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2386
Silicon Valley
Re: calculation simulation time of initial transie
Reply #6 - Sep 20th, 2006, 8:54pm
 
If I were having this problem, I would be tempted to place the following line in the netlist

Code:
printInstParams info what=inst where=logfile 



and then inspect the parameters for V5 (and perhaps all of the other sources as well) to see if I could figure out where that 12 μs was coming from.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
Paul Geraedts
Community Member
***
Offline

GIGO

Posts: 60
Enschede, Netherlands
Re: calculation simulation time of initial transie
Reply #7 - Sep 21st, 2006, 1:56am
 
All the sources in my circuit are voltage sources. Most of them are set to zero and are used to sense the current through specific transistors (it's a work-around related to the used MM11 transistors).

Only source V5 is time-varying. When I looked at the specific rawfile data,  I don't find anything unusual (the line you mentioned is already in the netlist, but the data is sent to rawfile).

Code:
Instance: V5
Model: vsource
Primitive: vsource
	   dc = 0 V
	 type = pulse
	delay = 0 s
   edgetype = linear
	 val0 = 1.2 V
	 val1 = 0 V
	 rise = 1 ps
	 fall = 1 ps
	width = infinity s
     offset = 0 V
	scale = 1
    stretch = 1
     sinedc = 0 V
	 ampl = 1 V
	 freq = 0 Hz
	ampl2 = 1 V
	freq2 = 0 Hz
 fmmodindex = 0
  fmmodfreq = 0 Hz
 fmmodfiles = [ ]
 ammodindex = 0
  ammodfreq = 0 Hz
 ammodphase = 0 Deg
	 damp = 0 1/s
	  td1 = 0 s
	  mag = 0 V
	phase = 0 Deg
	xfmag = 1 V/V
     pacmag = 0 V
   pacphase = 0 Deg
	    m = 1
	  tc1 = 0 1/C
	  tc2 = 0 C^-2
 



Paul
Back to top
 
 
View Profile   IP Logged
Paul Geraedts
Community Member
***
Offline

GIGO

Posts: 60
Enschede, Netherlands
Re: calculation simulation time of initial transie
Reply #8 - Sep 21st, 2006, 3:43am
 
Something else: isn't it strange that the time-varying sources are referred to t=tstart instead of t=0?

Paul
Back to top
 
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2386
Silicon Valley
Re: calculation simulation time of initial transie
Reply #9 - Sep 21st, 2006, 9:59pm
 
Paul,
   It is odd that Spectre does not give the period when it prints out all the parameter values for V5.

Did you set the pss start time to 12us? If so, that would explain where the 12us came from. But I believe you are correct; that should not affect the sources. Do you have evidence that the step transition in V5 comes at 12us rather than at 0? Perhaps just the message about V5 having a long onset to periodicity is confused by the non-zero start time.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
Paul Geraedts
Community Member
***
Offline

GIGO

Posts: 60
Enschede, Netherlands
Re: calculation simulation time of initial transie
Reply #10 - Sep 22nd, 2006, 12:46am
 
Ken,

I re-checked and the period of V5 is not part of the logfile. When I send it to rawfile the period is equal to 'nan' (the result of it being 'infinity'?).

tstart is set by the initial condition file which I set.

You're right. The simulation results show that the source is nicely referred to t=0. The message (and tonset) is wrong though.

So I seem to have two instead of one tstab parameters now.. : ).

Paul
Back to top
 
 
View Profile   IP Logged
Paul Geraedts
Community Member
***
Offline

GIGO

Posts: 60
Enschede, Netherlands
Re: calculation simulation time of initial transie
Reply #11 - Sep 22nd, 2006, 2:52am
 
I would like to emphasize though, that the problem is also occuring when you set tstart=0; see the attached logfile.

It is the result of the first of my 3 cascaded analyses. This time init is set to 320ns, as source V5 should be
active between t=0 and t=320ns. tstab is now set to 10us, after which most of the initial transients have dissipated.
(The value is just the result of a guess which resulted in a nice starting point for the first PSS iteration.)

A+B+C=(320ns+1ps)+10u+(4*160ns)=10.96us, so not 11.28us.

Fortunately, 11.28us is still a multiple of period in this case, so it does not give an 'offset'.  
Furthermore, the initial transient is calculating a new estimate of the period of steady-state, so no waste of simulation
time now. Although the calculation is again not in line with the manual.

Paul
Back to top
 
View Profile   IP Logged
Pages: 1
Send Topic Print
Copyright 2002-2024 Designer’s Guide Consulting, Inc. Designer’s Guide® is a registered trademark of Designer’s Guide Consulting, Inc. All rights reserved. Send comments or questions to editor@designers-guide.org. Consider submitting a paper or model.