• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. RF Design
  3. AC Noise : inductors and noiseless ports still making n...

Stats

  • Locked Locked
  • Replies 6
  • Subscribers 63
  • Views 12015
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AC Noise : inductors and noiseless ports still making noise

AncisMichele
AncisMichele over 3 years ago

Hi,

I am exploring noise simulation capabilities and I stumbled upon something that looks strange to me, namely that when I list the noise contributors for a certain circuit containing ideal inductors and noiseless ports (set specifically to that status), I still see noise coming from resistors associated with those components. I am wondering what is it that I am doing wrong here.

This is the Results Window:

So, given for instance that I did not specify any kind of external files for the ports, nor any resistance for the inductor primitives, and explicitly set "isnoisy=no"  to the output port (P2), why am I seeing noise from what is, in my understanding, ghost components?

I have OCR'd the netlist to tray and avoid last pitfall, just in case we want to have a base:

----------------------------------------- NETLIST ----------------------------------------

simulator lang=spectre

global 0

include "$SPECTRE_MODEL_PATH/our_lib.lib.scs" section=tt_pre
include "save.scs"

parameters fB=(8e+10 + 10000) fRF=80G fRF2=(8e+10 + 1000000) PB=-20 RL=50 \
Lg=175p Ls=35p nf=64 fwid=300n wireopt=19 vgs=450m

// Library name: mylib
// Cell name: mytest
// View nane: schematic
NO (net7 net3 nett netd net6 0) nfet_xxx w=300e-9*(nf) 1=28n m=1\
// other parameters here...
V_GS (net2 0) vsource dc=vgs type=dc
V_DS (vDD 0) vsource dc=800.0n type=dc
LG (vgs net3) inductor l=LG
L1 (nett 0) inductor l=LS
G_choke (vgs net2) inductor l=1u
D_choke (VDD net?) inductor l=1u
D_bypass (net7 net10) capacitor c=1u
G_bypass (net9 vgs) capacitor c=1u
P2 (net10 0) port r=RL num=2 type=sine isnoisy=no
P1 (net9 0) port r=50 num=1 type=sine freq2=fRF2 dbm2=-50 fundname2="fRF2" \
freqvec=[ fRF fRF2 fB ] dbmvec=[ -50 -50 PB ]
simulatorOptions options psfversion="1.4.0" reltol=e-3 vabstol=1e-6 \
iabstol=le-12 temp=27 tnom=27 scalem=1.0 scale=1.0 gmin=1e-12 rforce=1 \
vthmod=vthcc ivthn=300e-9 ivthp=70e-9 ivthw=0 ivthl=0 maxnotes=5 \
maxwarns=5 digits=5 cols-80 pivrel=le-3 sensfile="../psf/sens.output" \
checkLimitdest=pst vdsatnod=gds
parameters _acip3_sweep_power_=-40
sweepac sweep param=_acip3 sweep_power_ start=-40 stop=-30
sweepac sweep param=_acip3_sweep_power_ start=-40 stop=-30
+ lin=1 {
ac ac start=80G stop=80.002G out2=0 outl=net10 maxharm_nonlin=7 \
flin_out=80.002G fim_out=80.004G rfdbm=_acip3_sweep_power_ \
rf2_src=["P1"] rfl_src=["P1"] perturbation=ip3 annotate=status
}

dcOp dc write="spectre.dc" save=all maxiters=150 maxsteps=10000 \
annotate=status
dcOpInfo info what=oppoint where=rawfile
noise noise start=50G stop=90G oprobe=P2 iprobe=P1 separatenoise=yes \
annotate=status
sp sp ports=[P1 P2] start=50G stop=90G donoise=yes oprobe=P2 iprobe=P1 \
annotate=status
modelParameter info what=models where=rawfile
element info what=inst where=rawfile
outputParameter info what=output where=rawfile
designParamVals info what=parameters where=rawfile
primitives info what=primitives where=rawfile
subckts info what=subckts where=rawfile
save D_choke:1
saveOptions options save=allpub

--------------------------------------- END OF NETLIST -----------------------------------

NOTES: there are some extra simulations as I'm actually trying to build a bridge between SP and AC noise as far as NF is concerned.

This works well for those specific outputs (NF is consistent if you specify P2 as a "port" for the load), but somehow (and this is what I was trying to achieve in the first place), the standard AC noise output always includes all noise, no possibility to take the "load" noise out of the equation in an easy fashion. That's why I was looking at the contributors to try and isolate the load induced noise and have a confirmation of the NF result through another way. That's when I found that other components were unintendedly making noise.

Thanks & regards,

Michele

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 3 years ago

    Michele,

    Which version of spectre and Virtuoso are you using? There was certainly a problem in the past when using noise separation that it messed up the noise summary (it couldn't distinguish between the noise gains and the noise sources), and that appears to be what you're seeing. I can re-check behaviour and when this was fixed (I'm sure it is fixed, but I've not had a chance to try it today to make sure), but it would help to start from knowing the tool versions you're using.

    Thanks,

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • AncisMichele
    AncisMichele over 3 years ago in reply to Andrew Beckett

    Hi Andrew,

    this is what I get:

    I was under the impression that this is fairly new? 

    However, your suggestion is correct although I can't understand the appearance/disappearance of resistive components and noise files :-O

    If I remove the "separate sources" check, I get a standard noise summary but the highest contributor is still a noise file (attached to the now only port P1) which is not existent.

    Is this just a fancy way to call the source resistance?

    Regards,

    Michele

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 3 years ago in reply to AncisMichele

    Michele,

    I can't quite reproduce your problem with this testcase and versions (because it's incomplete and also I think this has a dependency on the models used). I don't think it's related to the noise separation problem, but essentially is this problem:

    Incorrect noise summary results when using certain combinations of IC/ICADVM and SPECTRE releases

    (I had a case with a customer a while back which led to me writing this article). It's fixed in ICADVM20.1 ISR22 - can you check with that and see whether it goes away? Both with and without noise separation.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 3 years ago in reply to AncisMichele

    Michele,

    I can't quite reproduce your problem with this testcase and versions (because it's incomplete and also I think this has a dependency on the models used). I don't think it's related to the noise separation problem, but essentially is this problem:

    Incorrect noise summary results when using certain combinations of IC/ICADVM and SPECTRE releases

    (I had a case with a customer a while back which led to me writing this article). It's fixed in ICADVM20.1 ISR22 - can you check with that and see whether it goes away? Both with and without noise separation.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
  • AncisMichele
    AncisMichele over 3 years ago in reply to Andrew Beckett

    Andrew,

    I can't access that part of the support right now. I have to fix that :-/

    But I don't understand why you say it's not related to source separation? I just showed above that if I take the separation out, I do not see those contributors anymore? What am I missing?

    There's of course the "ext_file_noise" thing which remains suspicious...

    Michele

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 3 years ago in reply to AncisMichele

    Yes, all the noise contributors get messed up. In the article it shows with and without noise separation, and in that example thermal and flicker noise is getting mixed up - essentially the names all get mangled. So that's why (I believe) you're getting this spurious ext_file_noise.

    You should get the support access fixed - because I can't repeat all the detail here.

    Andrew

    • Cancel
    • Vote Up +1 Vote Down
    • Cancel
  • AncisMichele
    AncisMichele over 3 years ago in reply to Andrew Beckett

    I'm on the case ;-)

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information