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.

SN74LVC1G175: Question about tpd

Part Number: SN74LVC1G175
Other Parts Discussed in Thread: SN74HCS72

I have a customer considering D-FF for a clock sync setup.

But they either need <5ns tpd or >10ns tpd for propagation delay from xCLK to Q

The DS lists the Max/Min over temp given different CL values...

1. Based on section 6.9 (-40℃~85℃), is it safe to say that for max CL of up to 50pF (including probe/jig capacitance when measuring), the maximum tpd for VCC = 5V over temp/process will be under 4ns, and the minimum tpd will be greater than 1.5ns?

If so, then there should be no problem achieving tpd <5ns with the above device, correct?

Is the above understanding correct?

2. In case the customer stacks 2,3 D-FF to get MTBF higher than product lifecycle, the MIN tpd would only be 1.5ns + 1.5ns + 1.5ns = 4.5ns
Is it possible to increase CL or do something, to ensure the minimum tpd over temp/process is > 3.5ns?
(If VCC = 1.8V, it looks like at 50pF the MIN tpd is 2.7ns...but then can't support CLK of 32.768MHz...)

If you know of any other small package devices, that support >32.768MHz CLK and VCC = 5V, with tpd >10ns (SN74HCS72 Schmitt trigger was one option, but there is no detail regarding minimum prop delay over temp) that would be helpful.

Regards,

Darren

  • Hi Darren,

    Darren (FAE) said:

    The DS lists the Max/Min over temp given different CL values...

    1. Based on section 6.9 (-40℃~85℃), is it safe to say that for max CL of up to 50pF (including probe/jig capacitance when measuring), the maximum tpd for VCC = 5V over temp/process will be under 4ns, and the minimum tpd will be greater than 1.5ns?

    Almost - note that this also includes a 10% variance in the supply (5V +/- 0.5V)

    Darren (FAE) said:

    If so, then there should be no problem achieving tpd <5ns with the above device, correct?

    Is the above understanding correct?

    Yes. If the customer is operating between -40C and +85C with a supply of 5V with less than 10% variation and a load of less than or equal to 50 pF, the delay from CLK to Q will be between 1.5ns and 4ns.

    Darren (FAE) said:

    2. In case the customer stacks 2,3 D-FF to get MTBF higher than product lifecycle, the MIN tpd would only be 1.5ns + 1.5ns + 1.5ns = 4.5ns
    Is it possible to increase CL or do something, to ensure the minimum tpd over temp/process is > 3.5ns?
    (If VCC = 1.8V, it looks like at 50pF the MIN tpd is 2.7ns...but then can't support CLK of 32.768MHz...)

    Putting devices in series will reduce MTBF (ie increase chance of failure). You can only reduce chance of failure by providing redundancy (parallel) and I would not recommend to parallel DFF devices directly.

    You can add load to increase delay - the output is basically just an RC circuit. I wouldn't recommend exceeding 50 pF though without a series current limiting resistor - which would also aid in the delay. Doing this also slows down the device and can prevent correct operation at higher frequencies.

    A better way to add just a nanosecond or two is to use long traces - 6 inches of trace = 1ns of delay.

    Darren (FAE) said:

    If you know of any other small package devices, that support >32.768MHz CLK and VCC = 5V, with tpd >10ns (SN74HCS72 Schmitt trigger was one option, but there is no detail regarding minimum prop delay over temp) that would be helpful.

    You may note that the HCS devices (both the 72 and the 74) have a typical delay of 8ns at 4.5V -- probably not what you're after.

    You can try the CD4000 family of logic -- they have pretty poor performance at 5V.

  • Hi Emrys,

    I appreciate the quick reply!

    I will keep looking then.

    Regarding putting the devices in series...maybe my explanation was wrong? 

    It comes from this literature. Specifically p9 or Figure 10...could help me understand this better?

  • Hey Darren,

    I see what you're talking about now - this is related to timing related failure (bit rate), not device related failures.

    My comments were regarding failures of physical devices -- I'm not an expert on signal analysis or bit error rate reduction, so I'll defer to the author on that one.