Stats

  • Locked Locked
  • Replies 3
  • Subscribers 64
  • Views 12393
  • 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

Convergence Issues causing simulation to Slowdown while using VerilogA models for a PLL-VCO Loop

Kulmani

Hi,

I have modelled a PLL using VerilogA, so PLL had many blocks which i modelled individually including PFD,DIVIDER, Charge Pumps, LPF etc.

All these blocks i was able to implement and verify at standalone with their respective functionalities and were very fast with very less simulation runtime

When i am putting all these blocks together as one unit to form the entire loop of the PLL with VCO ( which is also a veriloga model ) i am seeing a very slow simulation ( almost dead slow ) where it is taking almost an hour to achieve a runtime of 10ns, even stepsize going as bad as "400aS",which is just simply too bad and not desired. 

What i have tried ?

- At first when i ran the simulation it failed due to convergence issues ( Jacobian ) so i am using a cmin of 1fF to tackle any floating net issue. It helped to curb the convergence errors but made sim very sluggish. Any other way to avoid this Jacobian error ? 

- In my models there are some set of inputs in my PFD block which are present in my symbol as pins but are not used inside the functionality ( e.g Bias signals ) so these are not connected inside the veriloga code. So i tried connecting these nets to VSS_PFD using a huge R to avoid convergence issues but what i observed as that my VSS_PFD going to my PFD was raising to some voltage 0.55V causing the other components to malfunction. Simulation was faster when i was doing this. Any potential reasons for this and how to avoid it ? Is it correct at the first place ?

-  I am getting Trapezoidal Ringing error for a signal where the ringing looked like a very small spike, I ran with gear2only method it was slower again.

What i need help for ?

- I need to know how to avoid these convergence issues and make simulation faster as these are verilogA models and should not take so much run time. I am unable to understand why this is happening. Do i need to make some changes in my models or should i go with the convergence aids ?

Kindly help. I really need to find a solution this as i have spent a lot of time in modelling all these blocks and if these fail at top level it would be a disaster for me.

Thanks in advance !

 @andrewbeckett

Regards,

Kulmani

Parents

  • Dear Kulmani,

    I have been thinking about your issue and just have not had a minute or two to respond until now - my apologies!

    I might start by posting your spectre.out file from one of your "slow" simulations. That will help as it will contain both your tool versions as well as which version of spectre (pure spectre. +aps, ++aps, or spectre X).

    With respect to the error you noted concerning trapezoidal ringing, you might consider forcing the use of the "gear2only" integration algorithm from the transient simulation settings GUI.

    One concern I have with respect to your observation on the difference you noted in simulation times with your veriloga PFD model changes is that it may now contain hidden states or other issues with its veriloga code. The presence of hidden states can impact simulator performance, and in fact, precludes spectreRF analyses.

    There is an application notes that describes the issue with hidden states and means to modify several veriloga model examples to remove their hidden states. This note is at the Cadence Online Support site at URL:

    support.cadence.com/.../068d0000002It9iAAC

    Ken Kendurt provides a similar note at his site URL:

    designers-guide.org/.../hidden-state.pdf

    There are example VCO and DFF (used in your PFD) veriloga models without hidden states. You might consider an experiment where you substitute these for your veriloga models to determine if your top level PLL simulation times are significantly impacted.

    support.cadence.com/.../ArticleAttachmentPortal

    support.cadence.com/.../ArticleAttachmentPortal

    A second useful resource is the application note with regard to optimizing spectre simulation performance also at the on-line support portal at URL:

    support.cadence.com/.../ArticleAttachmentPortal


    Finally, you might re-run your existing PLL netlist with the +diagnose option enabled from the Setup->Environment GUI panel (or include it as an added command line option). In your subsequent spectre.out file, you will find further helpful information as your simulation slows. It will also provide information on your veriloga modules as this will run Linter on their code.

    I hope this provides a few possible things to explore Kulmani! Please, if possible, provide your spectre.out file as it will also help to provide further insight into other possible issues.

    Shawn

Reply

  • Dear Kulmani,

    I have been thinking about your issue and just have not had a minute or two to respond until now - my apologies!

    I might start by posting your spectre.out file from one of your "slow" simulations. That will help as it will contain both your tool versions as well as which version of spectre (pure spectre. +aps, ++aps, or spectre X).

    With respect to the error you noted concerning trapezoidal ringing, you might consider forcing the use of the "gear2only" integration algorithm from the transient simulation settings GUI.

    One concern I have with respect to your observation on the difference you noted in simulation times with your veriloga PFD model changes is that it may now contain hidden states or other issues with its veriloga code. The presence of hidden states can impact simulator performance, and in fact, precludes spectreRF analyses.

    There is an application notes that describes the issue with hidden states and means to modify several veriloga model examples to remove their hidden states. This note is at the Cadence Online Support site at URL:

    support.cadence.com/.../068d0000002It9iAAC

    Ken Kendurt provides a similar note at his site URL:

    designers-guide.org/.../hidden-state.pdf

    There are example VCO and DFF (used in your PFD) veriloga models without hidden states. You might consider an experiment where you substitute these for your veriloga models to determine if your top level PLL simulation times are significantly impacted.

    support.cadence.com/.../ArticleAttachmentPortal

    support.cadence.com/.../ArticleAttachmentPortal

    A second useful resource is the application note with regard to optimizing spectre simulation performance also at the on-line support portal at URL:

    support.cadence.com/.../ArticleAttachmentPortal


    Finally, you might re-run your existing PLL netlist with the +diagnose option enabled from the Setup->Environment GUI panel (or include it as an added command line option). In your subsequent spectre.out file, you will find further helpful information as your simulation slows. It will also provide information on your veriloga modules as this will run Linter on their code.

    I hope this provides a few possible things to explore Kulmani! Please, if possible, provide your spectre.out file as it will also help to provide further insight into other possible issues.

    Shawn

Children
  • in reply to ShawnLogan
    Unknown said:
    One concern I have with respect to your observation on the difference you noted in simulation times with your veriloga PFD model changes is that it may now contain hidden states or other issues with its veriloga code. The presence of hidden states can impact simulator performance, and in fact, precludes spectreRF analyses.

    Shawn,

    This isn't entirely true, so I wanted to make a small correction (sorry, me being pedantic again). Hidden states are a problem for RF analyses, but they're not for other analyses (e.g. transient). So it's not a concern about simulator performance - it's a perfectly reasonable approach for non-RF analyses in fact. The note on hidden states that you refer to (both the version on the Cadence site and on Ken's site) are really just talking about the impact on such variables to periodic analyses, which would then be missing information about the effect these hidden state variables have on the solution - and it's that which leads to convergence  difficulties in the RF analyses (Ken's note also talks about the fact that merely adding the attributes to suppress the check is not a way of solving the hidden states if they actually affect the solution, but this is solely talking about RF analyses).

    Regards,

    Andrew

  • in reply to Andrew Beckett

    Hi Andrew,

    Andrew Beckett said:
    Hidden states are a problem for RF analyses, but they're not for other analyses (e.g. transient).

    Thank you for making the correction concerning my comment on hidden states! I would far rather you correct me than let possibly lead others to misleading information!!

    I did happen to read that hidden states are an issue for RF analyses as I was preparing my note to Kulmani as I wanted to be sure of my comment. I was not entirely clear if they posed a potential convergence issue for either a conventional transient simulation or a transient simulation performed as the tstab portion of a pss analysis - so your correction helps me understand that!

    The only reason I still included the statement was in case Kulmani was attempting to run an RF analysis as I don't recall seeing the specific type of simulation he/she was performing. I did ask if he/she might post the spectre.out file from one of the failed simulations to better understand the specific type of analysis type. If Kulmani is still experiencing the convergence issue, hopefully he/she will either post an example of the spectre.out file or, perhaps, has already contacted customer support regarding the issue and no longer needs my thoughts.

    Thank you again Andrew. I remain humbled and appreciate your feedback!

    Shawn

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.