huber
Community Member
![* *](https://designers-guide.org/forum/Templates/Forum/default/stargold.gif) ![* *](https://designers-guide.org/forum/Templates/Forum/default/stargold.gif)
Offline
![](https://designers-guide.org/forum/avatars/kramer.gif)
GO BEARS!
Posts: 45
Los Angeles
|
Hi vivkr,
If you set up the simulation properly then frequency resolution is unimportant. Let T be the clock period. I simulate for 16*T using an input frequency of 7/(16*T), so in the DFT plot the signal is in the 7th bin and the 3rd harmonic is in the 5th bin. If you are worried about the 3rd harmonic being too high in frequency and getting attenuated in the tracking network (not an issue for me; my tracking bandwidth is very high) then you would want to do a two-tone test. In that case you would probablly want to use at least 32 points with inputs at 15/(32*T) and 14/(32*T) to keep the signals and intermods clustered together.
100 dB SFDR is very difficult to simulate. I have no personal experience with this, but another student here has been working on this for a while. One problem he ran into was using vpulse sources for clocks. The discontinuous derivative of a vpulse source causes spectre to revert from 2nd order integration methods (trap or gear2) to first order (backward Euler, I think) near the disconinuity, which hurts accuracy. This is a very small error that I don't notice at 80 dB SFDR, but at 100 dB SFDR it might be a problem. You can get around this by deriving your clocks from a vsin source. I have a VerilogA module that does this and still allows you to set the rise/fall times; let me know if you want it. Of course you can always just sharpen-up a sinwave with inverters. Again, this is a very small error so don't worry about it unless you've already tried everything else.
BTW, for 80 dB SFDR I am using reltol=1e-4, vabstol=1e-5, and iabstol=1e-11. I'm not sure what you would need for 100 dB.
One more thing: any parts of your T/H that settle slowly over many clock cyles (some switched-capacitor CMFB circuits do this) will kill your SFDR if they are not completely settled. A pss analysis will avoid this problem by guaranteeing that the solution is periodic, but it takes longer to simulate and won't work with VerilogA modules that have hidden state. The alternative is to just let the tran simulation run long enough to settle before you measure the SFDR; for me this takes ~32 clock cycles because of my peculiar opamp topology, so I have to simulate for 48 cycles total.
Good luck! -Dan
|