• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 14 subscribers
  • Views 1737 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ths788: Processing delay in the TDC does not corresponds with datasheet.

Dmitry Serebryakov
Prodigy 40 points
Part Number: THS788

What is actual delay from input pulse to output strobe goes low with empty FIFO ? It seems that the delay is much higher that described for sect. 8.5.2.4. I see near 2x19 clocks minimum delay instead of 5 clock period for 16 bits result output.

Is this correct or I missed some configuration bits ?

  • 0
    TI__Guru 62930 points
    Dmitry,
    It has been identified that there may be some additional delay in the FIFO to ALU path that is not accounted for in section 8.5.2.4.
    The exact additional delay is not fully quantified. This delay is speculated to be the time to preload FIFO data to ALU prior to load pulse for shifting out of shifted. There is some evidence that there is an additional (results length -5) * RCLK delay that needs to be added to latency range.
    It would be recommended to empirically validate range of latencies that your the THS788 achieves in your system with appropriate configuration.
    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    Prodigy 40 points

    Wade,
    The delay you mention will be acceptable, but I see approximately 38 Rclocks minimum delay for 16 bit results. It is higher than our limit approx. by 50 - 60 ns. We already bought ~100 chips and huge design work was done on cabling planning, other subsystems, etc. It will be very expensive for us to redesign the system with 90 TDC on this new delays.
    Can this delay be controlled ?
    Another question - can we use 212.333 MHz clock frequency to have the THS788 work synchronously with other stuff ? This will allow us to save some time on data resync and correction. I see it locks on this frequency (may be with slightly increased differential nonlinearity in result).

  • 0 in reply to Dmitry Serebryakov
    TI__Guru 62930 points
    I mis-spoke slightly. On the adder to the minimum delay, it would be an additional (result length +3 -5)* RCLK.
    There is no mechanism to alter this delay path.
    You can use faster RCLK, to reduce the absolute delay. It can support 300Mhz SDR, or 150Mhz DDR.
    With respect to using 212.333Mhz clock. Exceeding the clock input may work, but this is not tested in this condition, and some units may not operate properly.
    Additionally, this would alter the timing results as the 200Mhz clock is synthesized up to 1.2Ghz. This 1.2Ghz period is then divided by 64 in an interpolator for the lowest 6 bits. Instead of a 13.02ps LSB, the new LSB would be 12.26ps.
    The interpolator utilizes a DLL to calibrate the delay relative to the 1.2Ghz clock. It "should" track to the new faster clock and not introduce any new non-linearities. However, it not tested, characterized nor validated to operate at any frequency other than 200Mhz.
    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    Prodigy 40 points

    Can you verify my results with (Rlength+3)x2 minimal delay ? I must be sure it is not my mistake before we will start changing the design. Of course, I use maximum possible clock speed (300 or 320 MHz).

    I see difference with 12.26 ps bins between even and odd bins, with 13.02 ps I see almost ideal Gauss distribution.

    Thanks,

    Dmitry

  • 0 in reply to Dmitry Serebryakov
    TI__Guru 62930 points
    Dimitry,
    I can attempt to empirically validate your conditions and the latency range that will result.
    I am out of office until May 31, and this will be delayed until the first week of June.
    My setup is not ideal for this, but I think it will work I will let you know.
    In the meantime, can you provide me relevant register settings?

    You seeing different distribution on the bins for running faster is indication that there are some non-linearities exposed in the interpolator when operating above specification.

    Additionally, I wanted to make sure you are aware that this device has been placed on NRND (not recommended for new designs). This is due no longer having the design team available to support product.
    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    Prodigy 40 points

    Thanks !

    Register settings: 0x80 : 0xA620, 0x81 : 2, 0 : 3,  1 : 0.

    I will try to work with 8 bit result and reproduce the upper part of counter and FIFO in FPGA. I think this can save PCB design.

    So, two additional questions - what is actual FIFO depth - 15 or 16 results ? In other words - If the burst events occurs at 200 MHz speed, losses will start from 16th or 17th event ? The 300 Mhz Rclock is locked to main counter and interpolator, and after startup the phase remains stable relative to the internal 1200 MHz, am I right ?

    Unfortunately, the decision to use this TDC was made when it was not yet marked as NRND. When I see this status we immediately bought chips for a whole project, as we have no time for second attempt of the design.

    I was ready that some difficulties with this chip will arise, but expect the problems with readout at 300 MHz or accuracy. Both are OK. But I couldn't imagine the datasheet error in data delay, because this can be calculated from the schematics and can be easily verified.