• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 349 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320DM8168: HDPVSS Output Bus Timing

Lawrence Wong
Genius 16820 points

Part Number: TMS320DM8168

The data sheet shows the following…

Min delay time and Max delay time are specified as percentages of clock cycle. Specification is given for tc min of 6.06ns (165MHz). However, customer operate at 148.5MHz which has a tc of 6.73ns. Normally expect min and max delay to be fixed. Thus as the clock rate slows down timing margins get easier to meet. By making the percentages this does not happen in the same way.

Is it correct to define them as percentages of 148.5MHz? This would mean …

Min Delay = 6.73ns * 0.27 = 1.82ns

Max Delay = 6.73ns * 0.8 = 5.39ns

allowing minimal incremental gain by slowing the clock

In Errata Advisory 2.1.47

Workaround: There are two options for a workaround:
1. The external device connected to the HDVPSS interface can capture data on the
rising edge.
2. External logic can be used to invert (or delay) the clock to provide adequate setup
and hold times to meet the requirements of the external device.

for #1 a max delay of Tc*0.8 is impossible to capture data on rising edge

Also this advisory states that HDPVSS Out only supports falling edge clock and points us to SPRS614F for more information. SPRS614F makes no mention of this, so there is a lack of clarity to the timing on this interface.

Need clarification since datasheet and errata have invalid information

  • 0
    TI__Guru**** 170625 points

    Hi Lawrence,

    Seems that DM816x datasheet is not updated to reflect errata 2.1.47. See for reference DM814x datasheet and errata 3.0.24, DM814x datasheet seems to be up-to-date.

    Check also below e2e threads:

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    TI__Genius 16820 points

    Pavel,

    So what are correct delay time for the DM816x devices?  The DM814x datasheet list -1.2 to 2 ns.  Is it the same for DM816x?  When will the DM816x datasheet be updated since it is not correct and provide the incorrect information?

    Regards,

    Lawrence

  • 0 in reply to Lawrence Wong
    TI__Guru**** 170625 points

    Lawrence,

    Lawrence Wong said:
    So what are correct delay time for the DM816x devices?  The DM814x datasheet list -1.2 to 2 ns.  Is it the same for DM816x?

    DM814x and DM816x devices are very similar regarding HDVPSS, thus I expect we will have the same timing for DM816x. We have the same timing for DM8127 device, but different for DM38x device.

    I will ping our team to check with them also, hope they can confirm DM816x HDVPSS output timing.

    Lawrence Wong said:
    When will the DM816x datasheet be updated since it is not correct and provide the incorrect information?

    I am not aware of DM816x datasheet update schedule. I will ping our team to comment.

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    TI__Guru* 86115 points

    Hi Lawrence

    Thanks for bringing this to our attention. 

    From the internal discussion with Steve Clynes, capture what he stated (and was also pointed in the e2e threads Pavel posted)

    ---

    As I note in the post here (https://e2e.ti.com/support/processors/f/791/t/248897 )the original nomenclature in the Netra datasheet was VERY confusing. The crux of the issue though resolves to the following statement I believe…

    “The original datasheet incorrectly stated output transitions on the rising edge and gave timings with respect to that edge, but with adjusted numbers corresponding to a specific and max pixel clock frequency. This is obviously a broken methodology since it made it very difficult to calculate margins for other frequencies. For VOut clock to data it is the spread of max and min which is critical since this tells you where the window of uncertainty is, i.e. where you cannot capture data. In this case there is an uncertainty window of 3.21ns (4.85 – 1.64) that starts 1.64ns after the clock edge.”

    ---

    The datasheet were last updated in 2015 and while I understand the challenge with interpretations and how it is documented - given the device is NRND , we are not planning to make any datasheet updates unless absolutely necessary. 

    I also think that DM814x timings cannot be directly applied as it is a different device, different layout and pinmuxing - so while the IP is similar, the timings are not. 

    Hope this helps some. 

    Regards

    Mukul