Stats

  • Locked Locked
  • Replies 3
  • Subscribers 125
  • Views 16081
  • 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

Accurate delay measurement between two clocks

threepwood06

Hi,

I am currently struggling with measuring the delay between two clocks with a sufficient accuracy. The reference one is a fixed-phase clock, and the other one is a squared clock resulting of a circuit (kind of PLL) synthesis.
As I need to run a large amount of Monte-Carlo simulations in transient noise, I need to improve the simulation speed, while keeping a satisfactory delay measurement accuracy (<0.1ps), more specifically at 0V-crossings of the differential clocks. So I cannot simply set a max timestep <0.1ps as it would be far too long to simulate.
To sum up, I would need a very relaxed timestep on clock up and down levels, and a very short timestep only at rise/fall transitions.

For this purpose, I wrote a Verilog-A script
- using a timmer function to accurately emulate the reference clock 0V-crossing times (and get the related times with $abstime)
- using @(cross to get the 0V-crossing times of the synthesized clock: but this is not accurate enough (I see simulation noise around 3ps in Conservative). Indeed, the "cross" event occures at the simulation time following the effective 0V-crossing time; this could be sometimes >3ps, far not enough accurate for my purpose.
- I have tried to replace the cross with the "above" function, but it hasn't changed anything, whatever the time_tol value I put (<0.1ps for instance), the result is the same as with the "cross" function and the points are larger than >>0.1ps, weirdly.

So I have decided to give up Verilog-A to measure the delay between my two clocks.
I am currently trying to use the "delay" function of the Cadence Calculator as I guess it will "extrapolate" the time between two simulation points and therefore give a more accurate measurement of the 0V-crossing events, but when I try to compute the delay difference between the synthesized clock and the reference clock, it returns "0".

...

Could you please give me hints to dramatically improve my 0V-crossing time measurements while relaxing the simulation time?
- either by helping me in writing a more suitable Verilog-A script
- or by helping me in using the "delay" function of the calculator
- or maybe by providing me a "magic" Skill function?
Using AMS+Multithread simulator...

Thanks a lot in advance for your help and best regards.

  • I wouldn't expect the above function to be any different in terms of accuracy than cross. I would suggest you use the last_crossing (as well as @cross) which should then give a reasonable estimate of the actual cross time close to the @cross. Doing the measurement in the simulator where the time steps can at least be controlled to be close would make sense rather than relying on just using the delay function post-process, where you have no influence on the time steps used. There's not going to be a magic SKILL function that introduces more accuracy in the simulator (we don't have a Bladerunner type "enhance" function).

    I don't know how you're using delay, but using @cross to broadly get a timestep very close to the transition point together with delay in the calculator might also be a reasonable approach.

    You may need to tighten reltol further (and maybe relax lteratio to avoid it taking lots more timesteps) but I'd say this would be better dealt with via customer support where can really look at your setup and goals in more detail.

    Andrew.

  • in reply to Andrew Beckett

    Hi Andrew and thank you for your feedback,

    I have modified the VerilogA as you suggested:

    delay_int0 = last_crossing( V(ckp_meas_i,ckn_meas_i) , +1 );
    @( cross( V(ckp_meas_i,ckn_meas_i) , +1 ) ) begin
      if( flag_ref_redge == 1 ) begin
        delay_int = delay_int0 - t_ref_redge;
        flag_ref_redge = 0;
      end
    end

    ...but I get the same inaccuracy (here 0.6ps peak-to-peak due to simulation noise):

    Before to deal with the customer support, would you suggest something else I could try? I am currently using the default Conservative settings:

    *************************************************
    Transient Analysis `tran': time = (0 s -> 200 ns)
    *************************************************
    Trying `homotopy = gmin' for initial conditions.

    Notice from spectre during IC analysis, during transient analysis `tran'.
    Bad pivoting is found during DC analysis. Option dc_pivot_check=yes is recommended for possible improvement of convergence.

    DC simulation time: CPU = 7.81381 s, elapsed = 1.49161 s.

    Opening the PSFXL file ../psf/tran.tran.tran ...
    Important parameter values:
    start = 0 s
    outputstart = 0 s
    stop = 200 ns
    step = 200 ps
    maxstep = 2 ns
    ic = all
    useprevic = no
    skipdc = no
    reltol = 100e-06
    abstol(V) = 1 uV
    abstol(I) = 1 pA
    temp = 27 C
    tnom = 27 C
    tempeffects = all
    errpreset = conservative
    method = gear2only
    lteratio = 10
    relref = alllocal
    cmin = 0 F
    gmin = 1 pS
    rabsshort = 1 mOhm

    Thanks a lot in advance and best regards

  • in reply to threepwood06

    Realistically, investigating this without seeing the data (and checking the Verilog-A code etc) is going to be slightly tricky, so following it up through support makes sense. I don't see the post any more that you made asking about how to log a case with support (I assume you deleted it), so I'm guessing you figured out how to contact support.

    Andrew.

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.