AD9371: Does Lane Latency Confirm The "Deterministic Latency" Exist Or Not?

Hi All,

I am working subclass-1 concept. I've few doubts which are quite complex :

1)  I am seeing my lane latency is keep on changing b/w "1Multiframe and 49 Octet" To "1Multiframe 62 Octet" on each power-up.

     Does it means that there is no deterministic latency ?

2) How can we calculate LMFC_OFFSET for framer and deframer ?

3)  Do we need to set same LMFC_OFFSET value in FPGA which we are using in AD9371 ?

4)  How can we calculate RBD value ?

Regards,

Manish

Parents
  • +1
    •  Analog Employees 
    on May 21, 2020 4:19 PM 1 month ago

    Hi Manish, 

    the reported latency is the actual delay in the datpath (e.g. DAC serdes/transceiver, physical delays on the route, FPGA transceiver)  per lane. As you can see this varies from power up to power up. The latency is measured from the next LMFC edge after the SYNC is de-asserted to the moment when the lane receives the ILAS sequence  (transitions from CGS to ILAS).

    Once all lanes received the ILAS sequence they are aligned(released) to the next LMFC edge. 

    In you case you have a multiframe of 128 Bytes (K*F).

    This means the CGS/ ILAS transition in your case (1 multiframe 62 Bytes) happens in the middle of the multiframe which gives you the larges margin. 

    In your case the lanes are aligned to the second multiframe so you will have deterministic latency of 2 multiframes.   

    2/3)  I don't see a reason to modify the LMFC offsets on the framer and deframer in the same time, you should adjust the one or the other. I think these are device tree properties for the FPGA link peripheral and for the 9371 device too. 

    You would need to set these only if your lane latency would  be near the the edge of the multiframe (not your case,  but e.g. 1 multiframe 127 bytes)

    or could jump to the next multiframe during another powerup. In this case the release point could jump a whole multiframe, canceling the deterministic latency. In that case you would need to shift one of the LMFC to compensate the  lane latency variations.

    4) The RBD value should be changed only if you want to reduce the latency of the link, but this will reduce the margin. 

    Suppose your lane latency is always around 1 multiframe and 32 bytes and you can guarantee the variation on the latency is smaller than +/-32 bytes, then you can move the release point from multiframe 2 to 1 multiframe and 64 bytes. So in this case the RBD can be set to 64 bytes.   

    Laszlo

  • Hi Sir,

    Thanks so much to unleash the concepts behind this.

    I understood most of the things which you have mentioned but i have still two more queries:

    >> Once all lanes received the ILAS sequence they are aligned(released) to the next LMFC edge

    Does it means that it is aligned based on RBD if RBD = 1 then its is aligned to "next LMFC edge" ?

    In my case, I have set RBD = 31 so will it release (align) on 31st LMFC edge ? 

    >> As you can see power-2-power up variance exists in lane latency and it comes around 1Multiframe 62/49/52/54 Bytes so what will be the RBD value in my case ?

    Looking forward for your reply.

    Regards,

    Manish

  • Hi Sir,

    a) In my case , latency varies from 1 Multiframe 49 bytes to 1 Multiframe 62 bytes which falls almost in the middle of the second LMFC so my deterministic latency will be 2 LMFCs. Is it correct ? 

    b) If i make RBD = 32 then my latency will be 2 LMFC + 32 bytes and if i make it  RBD = 20  then my latency will be 2 LMFCs + 20 bytes. This means it trails LMFC by "X" octet. 

    Is my understanding correct ? 

    c) As you said RBD is used to reduce latency but somehow it adds "X" octet after LMFC edge so how can it be used to reduce latency ?  I am confused on this.  Kindly help to fix this confusion.

    Regards,

    Manish

  • +1
    •  Analog Employees 
    on May 28, 2020 3:28 AM 1 month ago in reply to manish3134

    a) correct

    b,c) if your latency varies between 1 Multiframe 49 bytes to 1 Multiframe 62 bytes setting a RBD lower than 62 will increase the deterministic  latency to 2 multiframes + RBD.   

    In order to lower the latency you need to set a value higher than 62 in your case. this will move the deterministic latency to 1 multiframe + RBD. 

    Laszlo

  • Yeah. Setting the value is a critical and a necessary task.

  • Hi @Inagy Sir,

    I would like to convey my sincere thanks to you to clarify each of the doubts.

    Regards,

    Manish

  • Hi Sir,

    1st ADI Lane Info

    root@manish:/sys/bus/platform/devices/8000c000.axi_jesd204_rx# cat lane0_info
    Errors: 0
    CGS state: DATA
    Initial Frame Synchronization: Yes
    Lane Latency: 1 Multi-frames and 55 Octets
    Initial Lane Alignment Sequence: Yes
    DID: 0, BID: 0, LID: 0, L: 2, SCR: 1, F: 4
    K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 0
    FCHK: 0x4A, CF: 0
    ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    FC: 4915200


    root@manish:/sys/bus/platform/devices/8000c000.axi_jesd204_rx# cat lane1_info
    Errors: 2
    CGS state: DATA
    Initial Frame Synchronization: Yes
    Lane Latency: 1 Multi-frames and 54 Octets
    Initial Lane Alignment Sequence: Yes
    DID: 0, BID: 0, LID: 1, L: 2, SCR: 1, F: 4
    K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 0
    FCHK: 0x4B, CF: 0
    ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    FC: 4915200


    2nd ADI Lane Info


    root@manish:/sys/bus/platform/devices/8001c000.axi_jesd204_rx# cat lane0_info
    Errors: 0
    CGS state: DATA
    Initial Frame Synchronization: Yes
    Lane Latency: 5 Multi-frames and 102 Octets
    Initial Lane Alignment Sequence: Yes
    DID: 0, BID: 0, LID: 0, L: 2, SCR: 1, F: 4
    K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 0
    FCHK: 0x4A, CF: 0
    ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    FC: 4915200


    root@manish:/sys/bus/platform/devices/8001c000.axi_jesd204_rx# cat lane1_info
    Errors: 0
    CGS state: DATA
    Initial Frame Synchronization: Yes
    Lane Latency: 5 Multi-frames and 105 Octets
    Initial Lane Alignment Sequence: Yes
    DID: 0, BID: 0, LID: 1, L: 2, SCR: 1, F: 4
    K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 0
    FCHK: 0x4B, CF: 0
    ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1

    SYREF_To_LMFC Delay

    root@manish:/sys/kernel/debug/iio/iio:device2# cat *lmfc*
    17 ---> Tx
    31 ---> Rx
    31 ---> RxOS



    root@manish:/sys/kernel/debug/iio/iio:device3# cat *lmfc*
    17 ---> Tx
    31 ---> Rx
    31 ---> RxOS

    Tx Side Observation:

    Query :

    a) Lane Latency is keep on changing after each ad9371_reinit. Is it right ?

    b) For subclass #1, I don't expect different lane to lane latency on each power up. Am i correct ?

    c) If Tx side obs are fixed ( Above results) then why lane latency does exist ?

    Regards,

    Manish

Reply
  • Hi Sir,

    1st ADI Lane Info

    root@manish:/sys/bus/platform/devices/8000c000.axi_jesd204_rx# cat lane0_info
    Errors: 0
    CGS state: DATA
    Initial Frame Synchronization: Yes
    Lane Latency: 1 Multi-frames and 55 Octets
    Initial Lane Alignment Sequence: Yes
    DID: 0, BID: 0, LID: 0, L: 2, SCR: 1, F: 4
    K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 0
    FCHK: 0x4A, CF: 0
    ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    FC: 4915200


    root@manish:/sys/bus/platform/devices/8000c000.axi_jesd204_rx# cat lane1_info
    Errors: 2
    CGS state: DATA
    Initial Frame Synchronization: Yes
    Lane Latency: 1 Multi-frames and 54 Octets
    Initial Lane Alignment Sequence: Yes
    DID: 0, BID: 0, LID: 1, L: 2, SCR: 1, F: 4
    K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 0
    FCHK: 0x4B, CF: 0
    ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    FC: 4915200


    2nd ADI Lane Info


    root@manish:/sys/bus/platform/devices/8001c000.axi_jesd204_rx# cat lane0_info
    Errors: 0
    CGS state: DATA
    Initial Frame Synchronization: Yes
    Lane Latency: 5 Multi-frames and 102 Octets
    Initial Lane Alignment Sequence: Yes
    DID: 0, BID: 0, LID: 0, L: 2, SCR: 1, F: 4
    K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 0
    FCHK: 0x4A, CF: 0
    ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    FC: 4915200


    root@manish:/sys/bus/platform/devices/8001c000.axi_jesd204_rx# cat lane1_info
    Errors: 0
    CGS state: DATA
    Initial Frame Synchronization: Yes
    Lane Latency: 5 Multi-frames and 105 Octets
    Initial Lane Alignment Sequence: Yes
    DID: 0, BID: 0, LID: 1, L: 2, SCR: 1, F: 4
    K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 0
    FCHK: 0x4B, CF: 0
    ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1

    SYREF_To_LMFC Delay

    root@manish:/sys/kernel/debug/iio/iio:device2# cat *lmfc*
    17 ---> Tx
    31 ---> Rx
    31 ---> RxOS



    root@manish:/sys/kernel/debug/iio/iio:device3# cat *lmfc*
    17 ---> Tx
    31 ---> Rx
    31 ---> RxOS

    Tx Side Observation:

    Query :

    a) Lane Latency is keep on changing after each ad9371_reinit. Is it right ?

    b) For subclass #1, I don't expect different lane to lane latency on each power up. Am i correct ?

    c) If Tx side obs are fixed ( Above results) then why lane latency does exist ?

    Regards,

    Manish

Children
  • +1
    •  Analog Employees 
    on Jul 6, 2020 9:27 AM 6 days ago in reply to manish3134

    Hi Manish,

    I am trying to understand the latency differences between the two links (8000c000 vs 8001c000)    1 multiframe vs. 5 multiframes. This will cause the the two links to have different deterministic latency. The difference between these two should be less than 1 LMFC period. 

    a) the reported Lane Latency is normal to vary from one boot to another.  This is not the deterministic latency that is obtained after lane alignment, it is the measured latency per lane. 

    b) In subclass 1 you will still see the same variation in the reported latency.

    c) the latency includes also the datapath that includes serialization - deserialization, not just the control path you pointed (SYSREF and SYNC)  

    Laszlo

  • Hi Sir,

    Thanks for addressing the queries. 

    I didn't understand few things:

    >>  The difference between these two should be less than 1 LMFC period

    a) How did we reach to this as JESD204B doc doesn't talk about this. Why cannot be more than        1-LMFC ?

    b) How can we achieve this if it should be less than 1 LMFC period ? 

    >> The reported Lane Latency is normal to vary from one boot to another.  This is not the deterministic latency that is obtained after lane alignment, it is the measured latency per lane

    If lane latency can vary from boot to boot and it should not be DL but a measured latency per lane then how can we achieve DL in the system ? What are the steps of achieving this ? We have done following changes to achieve this:

    1. Sysref to LMFC delay ( Please see above table for this)

    2. Sysref is aligned across all the devices and LMFC are aligned. The same is captured in the          FPGA.

    3. Set RBD  = 0x1F

    4. Set BUFFER_EARLY_RELEASE[16] 

    >> In subclass 1 you will still see the same variation in the reported latency

    a) This means to me that lane latency variation exists in the subclass-1 and it doesn't confirm about DL ? Is it correct ?

    b) However, I am confused here because if lane latency is keep on changing then the overall latency cannot be constant all the time. On each boot, my lane latency is keep on changing which will move the release point to next multi-frame or release point cannot be constant so it will eventually affect the overall latency. Is it correct ? 

    c) How lane latency is different then Total Link Latency ?

    d) Why cannot lane latency impacting overall latency in the system ? 

    e) How can we measure that release point is keeping on changing on each power up ?

    >> the latency includes also the datapath that includes serialization - deserialization, not just the control path you pointed (SYSREF and SYNC) 

    a) How can we achieve this ? 

    b) What are the ways to determine this ? 

    Please see signals which we have captured. Please let us know what are the other signals which we can probe and proof the DL in the system.

    Regards,

    Manish

    RX_MCS_Signals_Capture.PNG

    TX_MCS_Signals_Capture.PNG