Post Go back to editing

AD9364 TX/RX path latency

We have an application that is very sensitive to latency in both the TX and RX paths.

The AD9364 Reference Manual explains the latency due to the digital filters, but in addition to this latency, we are measuring an additional latency that is not explained in the data sheet or reference manual.

Our clock setup using the no-os drivers is as follows:
ad9361_set_trx_clock_chain: 960000000 480000000 240000000 120000000 60000000 60000000
ad9361_set_trx_clock_chain: 960000000 240000000 120000000 60000000 60000000 60000000

Looking at the AD9364 users guide "DIGITAL Rx BLOCK DELAY" it looks like I should be seeing a delay contribution from the digital filters of approx:
                  HB3           HB2           HB1   
RX path (2/240M) + (2/120M) + (7/60M) = 8.3ns + 16.6ns + 116ns = 140ns
TX path (2/120M) + (2/60M)  + 0             = 16.6ns + 33.8ns             =  50.4ns
 
= 190.4ns total delay for digital filters

I am using an ILA (logic analyzer) in our FPGA to capture the TX and RX data just before clocking in/out to the AD9364.  I am seeing a delay of approx. 800ns.

 

I know that the 190ns is only the digital filter delay.  Is there a description somewhere of what the source might be for the additional ~600ns delay I am measuring?

Most importantly for our application, is there anything that can be done to reduce the latency below the 800ns we are currently seeing?

 

Thank you for any assistance.

  • Please measure same using attached filter files generated using Wizard.

  • This is the ILA capture using the filter configuration supplied in ballsystems.c as is (with 19 taps)

    It is more difficult to determine when the received impulse begins, but looks like the group delay is now approx. 97 DATA_CLKs or ~808ns.

    This is using the same coefficients but setting taps to 32 (don't the FIR taps need to be in multiples of 16?)

    Just to maintain perspective:

    Has anyone ever measured the latency and achieved something less than what I am measuring?

  • Any thoughts on these measured delays?

    Is the 140ns delay in the BIST loopback expected? 

    Thanks,

  • Forgot to mention FIR taps in file are meant to be implemented in BB as i have not checked box against use internal FIR. 

    Yes you are right FIR taps will be multiples of 16 if you use internal FIR.

    What you get around 600ns is ok and if we remove the delay due to FPGA logic which is around 140 ns (BIST testing)

    460ns delay from AD9361 can be divided as  below

      TX RX  
    Analog filters 3.20E-08 3.20E-08  
    Conversion time 1.67E-08 8.33E-09  
    Digital filters 9.58E-08 6.67E-08  
    QEC/DC offset block 5.00E-08 5.00E-08  
    I/O block 3.33333E-08 3.33333E-08  
           
    Total 2.28E-07 1.90E-07 4.18E-07

    As you can see it approximate and in real time may very a little bit.

    What is your requirement?

  • Sripad,

    1.  The additional sources of latency you list are what I have been asking about for some time and this is the first I have seen them.  I'm guessing most of these are fixed and nothing we can improve aside from higher clock rates?

    2.  The 140ns is not delay in the FPGA logic.  As I have tried to make clear, the ILA inputs are attached at a point right when the signals are registered  out/in to the IDDR / ODDR, so we are still a ways off from your numbers.

    3.  If I disable the QEC/DC blocks, should I expect a corresponding decrease in latency of 100ns or is this delay incurred even if the correction blocks are bypassed?  I have already tried using the following to disable but see no change.

       ad9361_set_rx_rfdc_track_en_dis

       ad9361_set_rx_bbdc_track_en_dis

       ad9361_set_rx_quad_track_en_dis

    4.  Is the IO block delay what I should be seeing when using the BIST loopback (i.e. 33.3+33.3ns)?

    In any case, it looks like there are quite a few sources of latency other than those listed in the datasheet and reference manual.  This is the information I was after and it looks like the latency I am seeing is not going to get any better so I have may answer.

    In our application, we would need the total TX->RX latency as seen at the baseband interface to be <300ns.  Our baseband processor adds additional latency of course, but that is something that we understand and have control over.  It is the unknown sources of latency in the AD9364 that have had us stalled.

    I would like to suggest that some of this information makes it into the datasheet or reference manual.  Granted our latency requirements aren't the norm, but I could see the information being needed.

    Thanks,

  • 2. We should see only the IO delay and some delay from IO of FPGA but it is more so i thought it may be from FPGA logic. 3. Few delays are incurred even you bypass blocks(QEC,Digital filters)

    4. You should see IO block delay plus some delay from FPGA IO.

    You have already bypassed slowest filters to get less latency but wont be able to meet your requirement.

     

    Thanks for suggestion will try to add that in next release doc.

  • This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

    Thank you,
    EZ Admin
  • I have the same problem. Have you solved your problem?