1
\$\begingroup\$

Trying to makes sense of the following in this LTC1407 datasheet:

It is good practice to drive the LTC1407/LTC1407A CONV input first to avoid digital noise interference during the sample-to-hold transition triggered by CONV at the start of conversion.

The same datasheet also has the following note about CONV:

It is best for CONV to rise half a clock before SCK, when running the clock at rated speed.

So I thought CONV might be driven high at the falling edge of SCK.

But the statement about driving the CONV input first is confusing.

Does it mean CONV shouldn't be driven on the falling or rising edges of SCK and should be offset from those? (see the datasheet's timing diagram)

Looking at interfacing the ADC with Lattice LCMXO2-256 and running the FPGA's clock at the SCK frequency, but then if it needs this offset I would need a PLL (which it doesn't have) or a higher clock frequency to achieve the offset.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Driving SCK and CONV at the same time could cause a race condition as SCK rising edges after the rising edge of CONV are used to advance the data (and to do the actual conversions). It might be possible to drive CONV on the falling edge of SCK; I would put an extra buffer in the output to SCK which might generate enough of a delay to meet the objective on the datasheet. \$\endgroup\$
    – Peter Smith
    Mar 3, 2019 at 14:29
  • \$\begingroup\$ Can this buffer be implemented inside the FPGA or do I need a separate component? I would imagine I could do a string of NOTs, but they it would probably optimize this out during compilation. \$\endgroup\$
    – axk
    Mar 3, 2019 at 14:59

1 Answer 1

Reset to default
1
\$\begingroup\$

Take a snap shot of the timing diagram and mark it up (in red) with what the data sheet tells you in the timing table is my recommendation: -

enter image description here

The above (I believe) answers all your questions.

I would drive CONV on the falling edge of clock-cycle 34 and ensure that at least 1.2 ns elapses before clock-cycle 1 rises (apologies for this correction).

\$\endgroup\$
7
  • \$\begingroup\$ Conv can rise with the rising edge of cycle 34 but should rise 3ns before the rising edge of cycle 1. But wouldn't the disturbance that the note mentions be caused by any switching of SCK? \$\endgroup\$
    – axk
    Mar 3, 2019 at 16:24
  • \$\begingroup\$ No, CONV can rise on the falling edge of cycle 34. What page of the DS is the note you refer to? \$\endgroup\$
    – Andy aka
    Mar 3, 2019 at 16:28
  • \$\begingroup\$ Page 18, penultimate sentence in the first paragraph. \$\endgroup\$
    – axk
    Mar 3, 2019 at 16:34
  • 1
    \$\begingroup\$ I think this follows on from page 17 and the avoidance of jitter on the CONV signal as it enters the ADC. So, it seems, best practice is to ensure the CONV signal is produced for the CONV signal input exclusively. Having read page 17/18 and said what I have said, I've never done this with this ADC - just used an FPGA because it was talking to a dozen of these devices simultaneously and I never noticed those words AND never had a problem with jitter that I can remember. \$\endgroup\$
    – Andy aka
    Mar 3, 2019 at 16:46
  • \$\begingroup\$ I think the trick is to ensure that CONV is raised with enough time for the internal sampling to have completed before CLOCK 1 rises AND I don't see this as onerous. \$\endgroup\$
    – Andy aka
    Mar 3, 2019 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.