• 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. Custom IC Design
  3. Can't get results from a PAC sim

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 125
  • Views 2665
  • 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

Can't get results from a PAC sim

forXTer
forXTer over 3 years ago

Hi,

I am trying to build up a dc-dc converter model, but I am having issues with PAC analysis. I put together a very simple modulator show below. I can get transient and PSS sims to work just fine. All of the waveforms look as expected. When I add PAC analysis I get 0V output on VOUT across the entire frequency range. I would expect to see some DC gain and then the double pole from the LC. I'm not sure if I am missing something simple or if this is the wrong type of analysis to use.

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

    Did you specify the PAC Magnitude on one of the sources? Can you share your netlist (input.scs) file?

    Andrew 

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

    Hi Andrew,

    Yes, source V9 has pacm=1 (purple node). Netlist is below.

    // Library name: wk1
    // Cell name: Switch_Loop_Model
    // View name: schematic_1
    C5 (net3 VSSA) capacitor c=3m ic=0
    R8 (net4 VOUT) resistor r=1m
    R5 (VOUT net3) resistor r=5m
    L0 (SW net4) inductor l=330n ic=0
    V9 (VC VSSA) vsource dc=1 pacmag=1 pacphase=0 type=dc
    V3 (VREF 0) vsource dc=600.0m type=dc
    V1 (VIN 0) vsource dc=12 type=dc
    V0 (VDDA 0) vsource dc=3 type=dc
    V2 (VSSA 0) vsource dc=0 type=dc
    I14 (CLK RST SW net022) rs_ff vlogic_high=12 vlogic_low=0 vtrans=1.5 \
    tdel=0 trise=1n tfall=1n
    V4 (CLK VSSA) vsource type=pulse val0=0 val1=3 period=1u delay=0 rise=1n \
    fall=1n width=25n
    V6 (RAMP VSSA) vsource type=pulse val0=0 val1=3 period=1u delay=0 \
    rise=998n fall=1n width=1n
    E0 (RST VSSA RAMP VC) vcvs gain=1e6 min=0 max=3
    simulatorOptions options psfversion="1.1.0" reltol=1e-1 vabstol=1e-2 \
    iabstol=1e-3 temp=27 tnom=27 scalem=1.0 scale=1.0 gmin=1e-12 rforce=1 \
    maxnotes=5 maxwarns=5 digits=5 cols=80 dc_pivot_check=yes pivrel=1e-3 \
    sensfile="../psf/sens.output" dochecklimit=yes checklimitdest=both
    pss pss period=1u harms=7 errpreset=conservative tstab=2m
    + maxacfreq=1e10 maxperiods=2000 annotate=status
    pac pac start=1 stop=1G annotate=status
    primitives info what=primitives where=rawfile
    subckts info what=subckts where=rawfile
    designParamVals info what=parameters where=rawfile
    asserts info what=assert where=rawfile
    saveOptions options save=all pwr=all currents=all
    ahdl_include "/opt/cds_618-500.6p2/CEN/sw/tools/dfII/samples/artist/ahdlLib/rs_ff/veriloga/veriloga.va"

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

    The rs_ff model is not valid for PSS simulation because it contains hidden states. Due to a mistake at some point, a number of the models in ahdlLib have add the instrument_module attribute added to them which turns off Spectre RF's check for hidden states, despite the fact that the "q" variable clearly is a hidden state and will give incorrect PSS results.

    I had filed a change request a while back (CCR 2273950) to get this fixed, but that hasn't been done yet.

    Modelling the correct small-signal transfer of an RS flip-flop would be tricky anyway. Can you use a real RS flip-flop instead of a behavioural model?

    Andrew

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

    The rs_ff model is not valid for PSS simulation because it contains hidden states. Due to a mistake at some point, a number of the models in ahdlLib have add the instrument_module attribute added to them which turns off Spectre RF's check for hidden states, despite the fact that the "q" variable clearly is a hidden state and will give incorrect PSS results.

    I had filed a change request a while back (CCR 2273950) to get this fixed, but that hasn't been done yet.

    Modelling the correct small-signal transfer of an RS flip-flop would be tricky anyway. Can you use a real RS flip-flop instead of a behavioural model?

    Andrew

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

    Okay thanks Andrew, I can use something else in place of the rs_ff. Is there a list or way I can identify which ahdlLib cells have this attribute?

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

    A very large number have this attribute set (and shouldn't) - I don't think any of the flip-flop models are hidden-state free in ahdlLib (the models are relatively old and generally pre-date anyone thinking about ensuring they work with SpectreRF).

    There's a very good paper (by Ken Kundert) on the challenges of Hidden States in Verilog-A modelling here: https://designers-guide.org/analysis/hidden-state.pdf and this has some examples of D-type flip-flops (so not RS, but you can get the idea) and it discusses the idea of whether they model small-signal propagation or not. The models can be found here: Verilog-A models

    I checked which models simply by doing a grep for instrument_module in the veriloga.va files in the library. Some of them genuinely are instrumentation blocks (either sources or output monitors) but many are not.

    You might want to contact customer support to request a duplicate of CCR 2273950 be filed on your behalf to accelerate getting this fixed.

    Regards,

    Andrew

    • 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