Designer’s Guide Community

Paul Geraedts

Community Member

Offline

GIGO

Posts: 60
Enschede, Netherlands

crash PNoise
Mar 21^st, 2005, 11:02am

At the moment I'm working on a relaxation oscillator (which is both rather non-linear and stiff). Furthermore, some of its parts are still in Verilog-A.
Alhough transient and (autonomous) PSS analyses don't give any problems with the current models, Pnoise analysis ends with this message:

Quote:

**********************************************************
Periodic Noise Analysis `pnoise': freq = (0 Hz -> 2.5 MHz)
**********************************************************
Using the operating-point information generated by PSS analysis `pss'.

Warning from spectre during PNoise analysis `pnoise'.
PSS analysis may be insufficiently accurate for PNOISE analysis. Consider
tightening simulation tolerance
PSS analysis may be insufficiently accurate for PNOISE analysis. Consider
tightening simulation tolerance
The Floquet eigenspace computed by spectre PSS analysis appears to be
inaccurate. PNOISE computations may be inaccurate. Consider re-running
the simulation with smaller reltol and `method=gear2only'.
Internal error found in spectre at freq = 0 Hz during PNoise analysis `pnoise'.
Please run `getSpectreFiles' or send the netlist, the spectre log file,
the behavioral model files, and any other information that can help
identify the problem to support@cadence.com.
Assertion failed in file `ptv_pnoise.c' at line 895.
Assertion failed.

As stated in appendix A of the SpectreRF user guide, I've increased the accuracy of PSS up to 'Hard-III' (reltol=1E-7; vabstol=0.1E-9; iabstol=0.1E-12), but without any change in PNoise behavior. As such, I would really appreciate it, if somebody can answer the next questions.

I think the origin of this crash is either the discontinuities in the Verilog-A part or the non-linear and stiff character of this type of oscillator. How can one demonstrate that it's one or the other?

What are the 'necessary and sufficient' conditions for PNoise (and LPTV analyses in general) to give accurate results?

And finally, not really a question but more a call for opinions: do behavioral modeling and (quasi-)periodic analyses mix? (There's an obvious difference between behavioral modeling and compact modeling. I'm starting to get the feeling, I'm doing the latter. One could argue behavioral modeling is just to speed up transient analysis!)

Cheers, Paul

Back to top

IP Logged

Andrew Beckett

Senior Fellow

Offline

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

Posts: 1742
Bracknell, UK

Re: crash PNoise
Reply #1 - Mar 21^st, 2005, 1:35pm

Do you have any nport components in your circuit? I had a similar error (1 line number different) with an nport with thermalnoise set to yes:

PCR: 680272
Title: noise contribution of nport with thermalnoise=yes in pnoise

Which was fixed in 5.0.33.500.1.10. I believe the fix just missed IC5033 USR2 - so you'd need to also be using either the 1.10 version, or the first ISR based on USR2.

That's assuming this is the problem... what subversion of the IC tools are you using?

Regards,

Andrew.

Back to top

IP Logged

Paul Geraedts Community Member Offline GIGO Posts: 60 Enschede, Netherlands	Re: crash PNoise Reply #2 - Mar 22^nd, 2005, 1:39am I'm using version 5.0.33_USR2.34.8 and I don't use any nports. But don't get me wrong: I don't blame the tool. I simply ain't sure if I'm meeting PNoise' requirements. (I'm not expecting Spectre to handle everything I'm able to feed it : )
Back to top	IP Logged

Ken Kundert Global Moderator Offline Posts: 2384 Silicon Valley	Re: crash PNoise Reply #3 - Mar 22^nd, 2005, 8:54am The warning may be completely independent of the error. The problem may be caused by the fact you are sweeping from 0 Hz. Do you have flicker noise sources present in your circuit? Spectre should be able to handle this, but ... -Ken
Back to top	IP Logged

Andrew Beckett Senior Fellow Offline Life, don't talk to me about Life... Posts: 1742 Bracknell, UK	Re: crash PNoise Reply #4 - Mar 23^rd, 2005, 12:55am Paul, I'd try what Ken suggests, and then try USR3. If that doesn't work, you should probably contact customer support via your normal support channel. Almost certainly we'll need the netlist/models that you're using. Regards, Andrew.
Back to top	IP Logged

Paul Geraedts

Community Member

Offline

GIGO

Posts: 60
Enschede, Netherlands

Re: crash PNoise
Reply #5 - Mar 23^rd, 2005, 2:15am

First of all, Andrew and Ken, your help is much appreciated!

Incredible: it works! Although even when I disable all the flicker noise sources, there remains something at DC that causes the crash. Maybe it's the integrating nature of a relaxation oscillator?

I suspect this integrating nature will cause more problems; a PSD with a delta function in its origin doesn't seem hopeful on a computer. Maybe this causes the warning about the inaccurate Floquet eigenvectors? The noise results consist of huge values near DC..

I initially thought about the Verilog-A models as being the origin of the crash, because while using the previous version of one of them, I got a crash during PSS:

Quote:

======================================
`pss': time = (11.25 us -> 11.4613 us)
======================================
pss: time = 11.26 us (2.67 %), step = 528.2 ps (250 m%)
pss: time = 11.27 us (7.67 %), step = 528.2 ps (250 m%)
pss: time = 11.28 us (12.7 %), step = 528.2 ps (250 m%)
pss: time = 11.29 us (17.7 %), step = 528.2 ps (250 m%)
pss: time = 11.3 us (22.7 %), step = 528.2 ps (250 m%)
pss: time = 11.31 us (27.7 %), step = 528.2 ps (250 m%)
pss: time = 11.32 us (32.7 %), step = 528.2 ps (250 m%)
pss: time = 11.33 us (37.7 %), step = 528.2 ps (250 m%)
pss: time = 11.34 us (42.5 %), step = 528.2 ps (250 m%)
pss: time = 11.35 us (47.6 %), step = 311.9 ps (148 m%)
pss: time = 11.36 us (52.6 %), step = 168.3 ps (79.7 m%)
pss: time = 11.37 us (57.5 %), step = 221.6 ps (105 m%)
pss: time = 11.38 us (62.5 %), step = 234.3 ps (111 m%)
pss: time = 11.39 us (67.5 %), step = 304 ps (144 m%)
pss: time = 11.4 us (72.5 %), step = 411.2 ps (195 m%)
pss: time = 11.41 us (77.5 %), step = 528.2 ps (250 m%)
Time steps are continuously to be extremely small.
Conv norm = 11.9e+06, max dV(I14:idt0) = 1 V, took 300 ms.

PSS failed to converge. PSS will adjust tstab a little and try again.

======================================
`pss': time = (11.25 us -> 12.1303 us)
======================================

Internal error found in spectre at time = 11.25 us during periodic steady state
analysis `pss'. Please run `getSpectreFiles' or send the netlist, the
spectre log file, the behavioral model files, and any other information
that can help identify the problem to support@cadence.com.
Assertion failed in file `devices.c' at line 4587.
Assertion failed.

I'm using a small capacitor to overcome the hidden state problem of PSS (its voltage models a binary state variable). Just when Time steps are continuously to be extremely small, this variable is set by charging the capacitor through a small resistor; a too small resistor. By increasing this time constant a bit, PSS analysis converged successfully. Possibly interesting for others as well!

Thanks again,

Paul

P.S. Possibly the answer to one of my previous questions could provide me insight?
Quote:

What are the 'necessary and sufficient' conditions for PNoise (and LPTV analyses in general) to give accurate results?

Back to top

IP Logged

Paul Geraedts Community Member Offline GIGO Posts: 60 Enschede, Netherlands	Re: crash PNoise Reply #6 - Mar 23^rd, 2005, 11:21am Sorry, a bit sloppy there. Not a real delta function of course. I meant the white noise getting shaped by 1/(omega*C)^2, which grows unbound at small frequencies..
Back to top	IP Logged

Paul Geraedts Community Member Offline GIGO Posts: 60 Enschede, Netherlands	Re: crash PNoise Reply #7 - Mar 29^th, 2005, 3:23am Lets pinpoint my problem: Can PNoise analysis accurately predict the noise behavior of a relaxation oscillator, given its integrating nature?
Back to top	IP Logged

Ken Kundert Global Moderator Offline Posts: 2384 Silicon Valley	Re: crash PNoise Reply #8 - Mar 29^th, 2005, 8:26pm Yes, of course. -Ken
Back to top	IP Logged