I have encountered a problem with the time resolution of the printed data with 5.10.41_USR6.127.29.

I simulate a circuit with only a sinewave source (10MHz) for 1us with strobeperiod of 1u/512(=1.953125e-09) and take the DFT with the same time points(0 to 1u with 512 points). There are weird components at 14MHz, 34MHz etc. I traced this down to what data comes out when I use, say ocnPrint. The first six points are given below:

ocnPrint(?output "test.dat" ?numberNotation 'none VT("/in"))
==================
0                 0
1e-09             0.122411
3e-09             0.24298
5e-09             0.359895
7e-09             0.471397
9e-09             0.575808
==================
The x values are rounded to 1ns, but the y values correspond to 0, 1u/512, 2u/512 etc.! When I export the data to matlab and take a DFT of the second column, it is clean, as expected.

When I specify the step size in ocnPrint, the output is [using ocnPrint(?output "test.dat" ?from 0 ?to 1u ?step 1u/512 ?numberNotation 'none VT("/in")) ]
==================
0                 0
1.953125e-09      0.17986958
3.90625e-09       0.295957224
5.859375e-09      0.407805923
7.8125e-09        0.51381389
9.765625e-09      0.612462781
==================
Now the t values are right, but the y values are interpolated from the table before. When I take DFT in wavescan's calculator, it takes the DFT of these points and throws up horrible harmonics. So I am unable to find distortion correctly with strobing(whose main point is to be able to calculate distortion without interpolated points)

This is not affected by specifying number of digits in analog options, or precision in ocnPrint. It is also not affected by specifying the strobeperiod as 1u/512 or 1.953125e-09 or 1.953125n. This problem wasn't there in IC5141_ISR500.2.29 but I'd seen it in an even earlier version. The bottomline seems to be that the simulation is fine, the problem is with the way data is output and passed on to the calculator.

Hoping for a solution

Cheers
Nagendra

Hi,

It didn't work. Also, the problem is not just with CIW display from ocnPrint. When I take the DFT in calculator, it uses the strange x values to interpolate. Additionally, the rounding is only when strobeperiod is set. Without strobing, I get the following, again correct values, but not good enough to detect low level distortion because of interpolation in uniformly spaced DFT.

Nagendra

output of ocnPrint without strobing
==================
0                 0
1e-09             0.00628314
1.25e-09          0.0078539
1.75e-09          0.0109954
2.75e-09          0.0172779
4.75e-09          0.0298407
8.75e-09          0.0549502
1.55148e-08       0.0973281
2.34131e-08       0.146579
==================

Just realized that I may have confused the issue with inconsistent numbers. The numbers in the first post were with a 10MHz sinewave. I was folling around with it and in the next two, the numbers and the plot are with a 1MHz sinewave. The results from ocnPrint and drGetElem match in either case. Below is drGetElem for 10MHz wave, consistent with the first post.

drGetElem(y_vec, 0)
0.0
drGetElem(y_vec, 1)
0.1224107
drGetElem(y_vec, 2)
0.2429802
drGetElem(y_vec, 3)
0.359895
drGetElem(y_vec, 4)
0.4713967
drGetElem(y_vec, 5)
0.5758082
drGetElem(y_vec, 6)
0.671559

Your problem is a bug of Cadence Spectre Version-5.X.X.

Output data format is "sst2", if you run Spectre from Cadence ADE.

See head of "2/psf/spectre.out". The followings are extractions from it.
Quote:


If you change output data format to "psfbin", problem can be resolved even if you use Cadence Spectre Version-5.X.X.

If you want to change output data format to "psfbin", set like following in Cadence ADE.
     ADE > setup > Environment
     Enter "-format psfbin" in "userCmdLineOption". Here you must not enter '"'.

I checked following versions of Cadence Spectre.

@(#)$CDS: spectre  version 5.1.0 09/19/2007 10:08 (intelibm18.Cadence.COM) $
@(#)$CDS: spectre  version 6.2.0 09/19/2007 13:58 (usimlx112) $
@(#)$CDS: spectre  version 7.1.0 32bit 04/21/2009 11:50 (sjfdl189) $

This problem occurs only in Spectre 5.1.0.
This bug is fixed in both Spectre 6.2.0 and 7.1.0.
So if you use newer Spectre, you don't have to change data format at all.