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.

SN74LVC2G04: Output waveform rise/fall time details - query

Part Number: SN74LVC2G04
Other Parts Discussed in Thread: SN74AUC2G34,


I am using your SN74LVC2G04DCK dual buffer output device on my board for buffering my 25MHz clock input into two 25MHz outputs.

but I am seeing the output waveform fully distorted, as shown below. One is before the R2091 series resistor and the another one is after the series resistor.

some kind of overshoot and undershoot is coming in the output, which is reflecting in my end application RGMII TX/RX clocks as well..

Below is the schematics of it, (I have marked with RED color arrow in schematics where I probed the signals)

Please help me with the suggestions and guidance to overcome this.


Pradeep. S

  • Does "before" mean "left side"?

    The ringing in the "before" waveform is harmless. The reflections in the "after" waveform are not, and are probably caused by improper termination. See [FAQ] What happens when I connect a logic device's output to a 50 ohm transmission line?

    What is the characteristic impedance of your traces? LVC outputs are very strong (roughly 12 Ω at 3.3 V), so I suspect that the 22 Ω source termination resistors might be too low. Try 33 Ω.

    What is the length of the trace between U29 and R2091? It should be as short as possible.

    Did you really measure with 50 Ω inputs? This is not the same load as the high-impedance clock inputs of your devices.

  • Hi Clemens,

    Thanks a lot for helping me here..

    Yes, I meant left side means before the series termination. My trace length from U29 to R2091 is 25mils length only, and it is having Zo of 44.315 ohms.

    Let me try with other series terminations values 33E as well. 

    The clock output from buffer is connected to Marvell PHY 88E1512 XTAL input pin, below is its schematic via a capacitive divider to convert 3.3v to 1.8V clock before connecting to XTAL pin.

    Hope this might not be due to the rise/fall time limitations of the buffer. Please let me know if there is any suggestions.


    Pradeep. S

  • The optimal clock buffer for 1.8 V signals would be the SN74AUC2G34. Its inputs accept 3.3 V, and AUC outputs have dynamic drive strength and do not need termination. (Is TC_FPGA_CLK also 1.8 V? If not, use two 1G buffers.)

  • Hi Clemens,

    Quickly I have tested after changing 33E, 11E, 0E different series termination resistors as well..

    The waveform is not proper still. Signal going more worser, (sorry. I could not able to attach the signals at the moment..)

    I am thinking whether it might due to the drive strength or rise/fall time. Could you please provide the rise/fall time limitations of the output pins as we are having only input rise/fall times spec available in the datasheet as shown below.

    As you have suggested the different device for this application, we will try to check for the feasibility. but most probably we are planning to reuse this existing buffer. So, is there a way to still use this device with some optimizations and meet the required output.?

    Kindly looking for your suggestion.


    Pradeep. S

  • The input and output buffers are independent; the input rise/fall time has no effect on this.

    I suspect that the impedance of the capacitive divider does not match the trace impedance.
    With an AUC buffer running at 1.8 V, you would not need a divider.

  • Hi Clemens,

    I have tried replacing the capacitors using resistors 122ohm, 150ohm to output 1.8V.

    But I was seeing the similar waveform on buffer output, not much changes observed. Also, below is the waveforms of our buffer output clock going to Marvell PHY as reference input clock 25MHz shown in left side, and the right side waveform is RGMII RX clock generated on Marvell chip using this 25MHz clock. the waveform distortion in 25MHz is directly reflecting in the RGMII RXCLK as well..

    I want to add one more thing here, after the capacitive divider we are seeing the 1.8V clock is coming better as shown below, but I am not clear how the distorted waveform before the cap divider is now reflecting in my end RGMII RXCLK waveform....!!

    Kindly help me with your suggestions please..


    Pradeep. S

  • Hi Pradeep,

    The 'stair step' signal shown here:

    Is a result of the transmission line you are driving. It takes time for the signal to travel down the line and return, which will be equal to the time that the signal pauses at the intermediate state.

    This is what the signal looks like at the output of the buffer (between Z_S and R in the above drawing), but that is not where it is important to have a good signal integrity - it is important to have good signal integrity at the receiving device (at Z_L).

    Assuming your output impedance is fairly well matched to the line impedance (which it is fairly close), you shouldn't see any significant issues at the receiving device.

    I unfortunately cannot teach everything there is to know about transmission line theory via the forums - it is a very complex topic. Suffice it to say, if your signal looks good at the distant end, then the system will work fine.

  • Hi Emrys,

    Thanks for guiding me here with detailed information..

    Also, I found one more thing in my design which might be a factor for the issue here, but i'm not sure..

    The buffered output clocks from SN74LVC2G04 which are going to the farthest FPGA in our board are the ones having stair steps on the waveforms. The same buffer output going to nearest PLL AD9576's reference clock input pins is not having the stair step, instead it is very good as I shown in the attached excel having comparison of all signals with its trace length, sink, source details. Please check it once. Also, the schematic can be found here.


    So, I am thinking that trace lengths below 2000 mils are seems to be good, but the traces travel beyond 7000mils are having issues here. So, Is this issue related to the lengthy trace lengths merely??? Kindly requesting for your comments.


    Pradeep. S

  • Yes; see the FAQ I linked in my first answer.