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.

L138 Input Rise/Fall time requirement

Other Parts Discussed in Thread: OMAP-L138

Hello,

Does the L138 have specific input rise & fall time requirement for signals like RESET, CLKIN & GPIOs?

I am trying to reduce the slew rate of some signals, one of the being RESET and CLKIN to reduce noise however I could not find a spec for it

  • Look at Table 5.2 in the OMAP-L138 datasheet for the transition time parameter.  This applies to all inputs unless otherwise noted.

  • I looked in further detail on the L138 input rise/fall time requirements specification in Section 5.2, where Transition time for all inputs (10-90%) should meet 0.25P (period) or 10nS, whichever is smaller. Maintaining transition times as fast as possible is recommended  to improve noise immunity on input signals.

     

    I would like to see some clarification on this statement in the spec.

    I am finding it hard to meet this signal requirement for all my signals, i.e. SPI, Keypad, peripheral interrupt to the L138 GPIO.

    I could not possibly be adding Schmitt triggers for all these input signals.

     

    Say for example, a peripheral interrupt to L138 has a rise/fall time of 50ns.

    Would this cause any issues to the system?

    If I am running the ARM at 144Mhz, ~6.8ns clocking, would a 50nS rise/fall time signal to the input possibly generate more then 1 interrupt due to multiple debounce because of a noisy signal? would this cause a system problem

  • hi

    any experts can verify or advice on this?

  • tehoaislimau said:

    Say for example, a peripheral interrupt to L138 has a rise/fall time of 50ns.

    Would this cause any issues to the system?

    Supplying a rise time that is greater than 10nSec may make the pin to be less noise immune. With a slower rise time, other higher frequency switching noises (within close proximity) may couple on the (slower pin)  and cause glitches (false positives) to appear internally  that cannot be seeing at the pin.

     

    tehoaislimau said:
    If I am running the ARM at 144Mhz, ~6.8ns clocking, would a 50nS rise/fall time signal to the input possibly generate more then 1 interrupt due to multiple debounce because of a noisy signal? would this cause a system problem

    I'm not sure if I can supply a definite yes or no, because noise issues are (most of the time) related to board layout, but in general, the faster the edge, the better the noise immunity of the signal. (Assuming that you properly control overshoot/undershoot)

     

  • Hi,

    I've got a similar question. In our design, the part connecting to OMAP-L138 SPI port may have up to 20ns rise and fall times.
    From the answer above, it seems that the 10ns requirement is driven by a risk of external noise from adjacent signals coupling into the input causing a glitch.
    1. Is there any other reason for the 10ns requirement on rise/fall times for inputs or is it purely down to the risk of noise coupled into the signal?
    2. If it's purely driven by the risk of noise creating a glitch, isn't this requirement already covered by signal monotonicity under 6.2?
    3. You mention that a glitch may appear internally and cannot be seen on the pin. It's not clear what aspect couldn't be seen on the pin. Could you please help clarify if noise injection would be from the pcb layout or internal to OMAP silicon?
    4. If the latter (=internal to OMAP), what testing is recommended to mitigate the noise injection risk on input signals with rise/fall times >10ns?

    Thanks for your answers
    Dzenan
  • Hello Dzenan,

    Welcome to TI E2E Forum!

    Answering your questions,

    Q.1. Is there any other reason for the 10ns requirement on rise/fall times for inputs or is it purely down to the risk of noise coupled into the signal?

    Ans: Besides the noise immunity issue, rise/fall time affects delay through the input buffer and can begin to impact timing.

    Q.2. If it's purely driven by the risk of noise creating a glitch, isn't this requirement already covered by signal monotonicity under 6.2?

    Ans: Refer Q.1 answer

    Q.3. You mention that a glitch may appear internally and cannot be seen on the pin. It's not clear what aspect couldn't be seen on the pin. Could you please help clarify if noise injection would be from the pcb layout or internal to OMAP silicon?

    Ans: Sometimes you might not be able to see noise at the probe point with a slower scope, but it may appear at the device pin.  Especially with a BGA, where you usually can’t get directly to the ball, this can be an issue.

    Q.4. If the latter (=internal to OMAP), what testing is recommended to mitigate the noise injection risk on input signals with rise/fall times >10ns?

    Ans: In general, follow best practices for signal integrity; keep clock edges fast and monotonic, try not to route noisy signals near your clocks, have a solid ground plane, etc.  But there isn’t any recommended testing for rise and fall times over 10ns; they are not supported.  Further, the spec states that the transition time must be <=10ns or 0.25* the period of the clock, whichever is smaller.  Depending on the clock frequency, a transition time of less than 10ns may be required.

     

    Regards,

    Senthil