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.

TPLD1202-DYY-EVM: Pulse delay blocks showing sensitivity to duty cycle. Using Interconnect Studio 1.4.0

Part Number: TPLD1202-DYY-EVM

Tool/software:

Pulse delay block are showing sensitivity to pulse duty cycle. I placed 3 delay blocks with a 47 count. The delay blocks are clocked at 10kHz. The top delay block receives a pulse with a 51% duty cycle at 10ms period.

The middle delay block receives a 50% duty cycle, and the bottom delay block receives a 49% duty cycle. 

Only the middle delay block (with its 50% duty cycle) properly delays the pulse.

Chris Stell

  • I installed Interconnect Studio 1.5.0 and this did not fix the issue.

  • Hi Chris,

    The 49% and 51% appear not to work properly because of the signal timing. The simulation is (probably, I don't have time today to test on real hardware) correct. Here's what's happening:

    • The 49% duty cycle signal falls just before the 49th input clock cycle, before the delay block has a chance to go high, meaning it will never trigger the delay. The delay block basically works like a digital filter and will filter out any pulse that is shorter than a minimum time as defined by the data and clock signal. In this case, that's (1 / 10000) x (47 + 2) = 4.9ms. Note that your 49% duty cycle signal at 10ms period is right on the edge of that timing and so might not get caught every time or at all. This is easily seen on the first clock pulse, where the 49% signal (green) falls just before the 49th clock signal (orange)

    • The 51% duty cycle has the inverse problem of the above where it rises high again before the delay block has a chance to fall low, meaning once the delay block is initially triggered high, it will keep getting retriggered in perpetuity.

    In both cases, a change of 1% in duty cycle has made it so your shifted inputs are each off by 1 clock cycle. I'm not sure if you configured timing to be so tight on purpose or not, but if you reduce give a slightly wider bound everything works as expected (delay block data of 45 instead of 47):

    Keep in mind that due to signal synchronization, the total delay from any delay block is DATA + 2. So 47 gives 49 clock cycles of delay rather than 47.

    Let me know if you need any more help.

    Best,

    Malcolm