As of July 1, 2021, Google will discontinue the RSS-to-email subscriptions service.
Hence, the email alerts will be impacted while we explore other options. Please stay tuned for further communication from us.
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 !
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:
Ken Kendurt provides a similar note at his site URL:
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.
A second useful resource is the application note with regard to optimizing spectre simulation performance also at the on-line support portal at URL:
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.
ShawnLogan 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.
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).
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!