• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 14 subscribers
  • Views 638 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 - Negative results format doesn't work?

Gianluca Boso81
Prodigy 20 points
Other Parts Discussed in Thread: THS788

Dear all,

I am working on a project involving the THS788 Timing Measurement Unit. Unfortunately, even if the part is NRND, we started the project many months ago and decided to use this chip.

- We feed the THS788 sync input and channel A input with the same signal delayed by few hundreds of ps.

- We read the results from the internal channel A register through the SPI interface (register 10h–12h for channel A)

- we use a configuration with the counter set to 18 bit and the external serial interface set to 16 bit (this shouldn't influence our read-out since at the moment we are reading all 40 bits direclty through the slow SPI interface)

The problem is:

- at low frequencies (below few MHz) everything works fine and the time stamps we read looks like this:

49bdd 0000 0011
49bdd 0000 0011
49bdd 0000 0010

49bdd 0000 0011
49bdd 0000 0010
49bdd 0000 0011

If I ignore the first 16 bits (don't know what they mean) I get a meaningful timestamp that changes value if I change the delay.

- at higher frequencies (when maybe there is a chance to get a negative number due to a sync arriving during the conversion), with the same setup, the time stamps look like this:

8MHz

49bdd 0000 0011
49bdd 0000 2544
49bdd 0000 2544
49bdd 0000 0010
49bdd 0000 0011
49bdd 0000 0011
49bdd 0000 0011

16 MHz

49bdd ffff 2811
49bdd ffff 2810
49bdd ffff 2810
49bdd ffff 2810
49bdd ffff 2811
49bdd ffff 2811
49bdd ffff 2810

The fast interface (LVDS) looks exactly the same with the only difference that when we set it to 16-bit we get only the 16 LSB of the entire register (49bdd ffff 2811 becomes 2811).

If I try to do the 2s-complement of those numbers (with 24bit since there should be 18 bit counter + 6 interpolator) I get a "huge" negative number...

Could you help out please? Is there something I am not taking into account in the number conversion?

Thanks,

Gianluca

  • 0
    TI__Guru 62930 points
    Gianluca,
    I am not certain on the behavior of reading through the host interface to get the results register when external results data is set to lower than 40 bits. I suspect that the data placed in the register will correspond to what is set for the results output. If I am right, the upper bits maybe garbage.
    You can quickly test this by changing the results interface to 40bits along with 34bit counter.

    Running at the higher rates, may cause the fifo to become full as the results interface will take longer to process each timestamp.
    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    Prodigy 20 points

    Dear Wade,

    thank you for the reply. I will try to set the result interface to 40 bits with 34 bits of counter to check if there is any change.

    Anyway, even ignoring the MSBs in the register, I cannot explain the behaviour of the chip. Even if the fifo fills up, the results should be consistent (I will just miss some timestamps, correct?) while at higher rates I get negative numbers that I don't know how to convert.

    With the same sync to channel A difference at 1 MHz I get 49bdd 0000 0011 (which is ok if I ignore the last MSBs ) while at 16 MHz I get 49bdd ffff 2810. How should I convert this number to get back to my original timestamp?

    With the fast interface I get exactly the same results, just truncated to the specific number of bits I set (16 bit for example).

    Thanks,

    Gianluca

  • 0 in reply to Gianluca Boso81
    TI__Guru 62930 points
    Gianluca,
    The timing for generating a timestamp is based on the load pulse in the serial shift register. This timing also influences what sync value is getting used at the time of the timestamp generation.
    Since you are applying a sync and event every 62.5ns, you will overrun the FIFO very quickly.
    What is your RCLK frequency set to? SDR or DDR?

    You can also speed up RCLK to max of 300Mhz. This will speed up the load pulse timing. See section 8.5.2.4 in datasheet.

    I think the root of your problem is that you are calculating timestamps from old events and new syncs. The FIFO will always use the oldest event. So, likely it is using an event 15 sync's ago. This will cause the counter to have rolled over. This will invalidate the ability to calculate a true relative offset.

    I suggest you run some experiments with larger counter, faster RCLK.
    Ideally if you can reduce your sync frequency, then this would help as well.

    Regards,
    Wade