• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 33 subscribers
  • Views 884 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.

DS32EL0421/124 Locking and Timing

Amanda Ross95
Intellectual 2740 points
Other Parts Discussed in Thread: DS32EL0421

Good Morning,

I have a couple questions regarding using an FPGA to deserialize a data stream coming from the DS32EL0421.

  • On this previous e2e thread (same design being referenced here with Sanjay) you talked about using K28.5 control symbols and comma sequences with this device. The plan is to use those comma sequences in conjunction with test sequences to properly identify and organize streams of data once they are deserialized by the FPGA. The question is what is how often would the control symbols need to be sent to ensure the data is locked if they have a frame rate that is variable? There is an app note that reads every 5us but that seems pretty frequent and would slow down their overall data rate. 
  • Another question was regarding this timing app note. In 'Section 3: Serializer Register Programmability' it shows this table and identifies the default register setting for sample and hold times:

If they have a data valid period of 800ps on the sensor spec and factor in skew for cable (40ps), and clk buffers, and a lane to lane skew of 50ps, what type of setup and hold time would be safe to program into the serializer for their setup? Given all this, would it be alright to remain with the default?

Sanjay can comment on anything I may have missed or if there are any adjustments he wants to make. 

Thanks so much for your time,

-Amanda

  • 0
    TI__Mastermind 29655 points

    Hi Amanda,

    Thanks for the post, and sorry for the delay. Please see responses below:

    1. If Remote Sense is disabled, it is good to send IDLE characters every 500 us (instead of 5 us) to verify that there is good initial data alignment while not causing excessive overhead. The customer can certainly align the data less often, but they run the risk of skew causing the data to become misaligned.

    2.  Is it possible to see a parametric table and timing diagram for the FPGA that is driving the TxIN and TxCLKIN of the serializer? I think I understand this question, but want to make sure. This table allows you to sample the data within a 350 ps window, and it simply means that this window is shiftable, depending on where the incoming data from the FPGA is guaranteed to be valid. If I assume that the cable and lane-to-lane skew affects the left and right margin of each bit equally, I can assume that there is (40+50)/2 = 45 ps skew on the left-side and 45 ps skew on the right-side, like so:

    Since you have an 800 ps data valid time, I predict that you will need to ensure that the DS32EL0421 setup time is greater than (45 ps + FPGA min. setup time) to ensure that the beginning of the DS32EL0421 sampling window occurs after the FPGA input data is stable.

    Since I do not have the customer's setup-time, I am not able to estimate this, but hopefully the information above gives guidance about how to determine an appropriate setting here. To me, the default 550 ps wait-time after the clock's rising/falling edge should be sufficient to begin sampling data. 

    Thanks,

    Michael