关于AD9361的多芯片同步的问题

TUJzzz

背景交代：小弟最近做的项目中需要用到4片AD9361芯片，由DSP配置9361，9361收下来的数据发往FPGA，最近将数据速率提升一倍之后（AD采样时钟翻倍25M-->50M，9361与FPGA的数字接口时钟100M-->200M），数字接口的时序乱了，手动调整接收通路的数据延迟和时钟（可通过修改9361寄存器来改变时钟和数据延迟,详情见官方文档-->Digital Interface Timing Verification [Analog Devices Wiki]），之后调用官方驱动中的 ‘ad9361_do_mcs’函数进行多芯片同步（MCS）功能去同步各个9361和fpga之间数字接口的时钟相位。（有关MCS功能可以参考AD9361 Reference ManualUG-570,87-89页）。ad9361_do_mcs程序如下：

问题：1，函数接口有，master和slave的概念，但是我一直没有明白是如何确定哪块9361是master的
          2，图一红标那里将master9361的延迟参数取出来写入了slave9361中，关于这一步没有理解他含义，
          假设master9361的 clk_delay=0,data_delay=5;
                 slave9361的   clk_delay=0,data_delay=10;
        那么我将master的参数用在slave上的话，肯定是不行啊，实际跑出来的效果也是如此，注释掉图一红标四行代码之后，接口时序正常，如果保留的话，会有2片9361的数字接口时序混乱。
  其他说明：ad9361_do_mcs函数是适配两块9361的，已经做了适配4块936的更改。也准备再官方论坛上提问这个问题。
         有些表述不准确的地方，还望海涵，不知论坛是否有做过相关东西的大佬能给小弟指点迷津。
AD9361_Reference_Manual_UG-570.pdf (2.03 MB, 下载次数: 38 )

2023-8-1 09:52 上传

点击文件名下载附件

拾冠

1，函数接口有，master和slave的概念，但是我一直没有明白是如何确定哪块9361是master的
没有这两个区别，应该只是命名，从它同步原理来说，都是靠外部同步脉冲输入做同步，所以9361芯片间没有区别
2，图一红标那里将master9361的延迟参数取出来写入了slave9361中，关于这一步没有理解他含义
调整延迟建议使用fpga去调，寄存器调整只是一个额外手段，给fpga无法调整或不使用fpga的板使用的。这个写法我认为是多芯片同步时，将多个芯片的时钟和数据延迟设置成一致的。原因是在做完多芯片同步之后，需要测量芯片输出的data_clk来验证是否同步完成，而9361寄存器中设置的延迟可能会对这个输出有影响，所以多芯片同步的推荐状态是设置一样的芯片延迟，数据对齐由fpga调整，然后发两个同步脉冲来完成同步。

我没使用过9361的多芯片同步功能，但是有在使用其它功能，看手册的理解是这样的。

JustdoitAbel

你把时钟改了后，timming参数应该不一样了吧

TUJzzz

JustdoitAbel 发表于 2023-8-1 11:10
你把时钟改了后，timming参数应该不一样了吧

时钟改了之后，重新手动测的timing参数，那部分代码提取的master9361的timing参数，也就是时钟更改后的参数。整个MCS过程都是在更改后的时钟域下进行，MCS前后不涉及时钟的改动。

中国梅西

？？？？不知道 说什么好的

TUJzzz

拾冠 发表于 2023-8-1 14:21
1，函数接口有，master和slave的概念，但是我一直没有明白是如何确定哪块9361是master的
没有这两个区别， ...

非常感谢您的回复！
    针对我的一个问题，我感觉也确实如您所说，因为sync脉冲是在FPGA中，跟9361的REF_CLK同源的一个时钟域下产生的，无法保证跟某一块9361的data_clk的相位是同步的，master和slave的概念可能只是官方的代码编写习惯问题，我后续也会试着把其他9361的当作maser，看看程序运行结果是否正常，结果也会在后续回复中与您分享。
    针对我的第二个问题，使用FPGA中的IO_DELAY去微调时钟数据延迟，我觉得是一种方法，之前一直参照官方文档，直接调整9361寄存器，忽略了这一方向。“而9361寄存器中设置的延迟可能会对这个输出有影响”，这个我也有相同的顾虑，所以在手动调整寄存器时尽量只调整了data_delay,不动clk_delay(因为MCS会更改data_clk的相位)。
    我觉得您的这个处理方案完全可行，不合理的地方在于官方文档里一点没有提到这个，因为如‘Digital Interface Timing Verification [Analog Devices Wiki]’这个文档所提的，整个的是一套自动化调整的方案（我这个项目出于各方面的原因领导没有选择自动化的方案，只让手动调整，板卡数量不多），如果需要FPGA侧去微调延迟，那么一套程序应该就不能适用所有板卡，大批量的板卡就需要耗费很多人力去调试这个，所以官方本意应该是不涉及fpga侧微调的，那么他配套的这部分代码（ad9361_do_mcs），就显得尤为奇怪，也是我的疑惑所在。
    我没有研究FMCOMMS这个官方板卡的整套驱动，可能有很多地方理解的不对。
    已经在ADI官方论坛发布了相同的问题，您有兴趣的话可以跟我一起关注后续。
    链接：some doubts about ad9361_do_mcs - Q&A - Design Support AD9361/AD9363/AD9364 - EngineerZone (analog.com)

拾冠

The tuning may be done either in FPGA, AD9361 or both (though not necessary). The FPGA tuning may be the preferred option for you, as it can compensate for the high fan-out clock buffers, however, since not all FPGA devices have this option - in the ADI reference designs and software - we don't use the FPGA, and stick with the AD9361 tuning only.这是官方时序调整的第二段话，上次回答其实我也提了，使用fpga调整是一种“preferred”的方案。首先既然使用软件能调延迟来对齐时钟和数据，那么使用fpga肯定也行，原理应该是进测试模式发prbs，这个写一段逻辑就可以实现。其次接口这边应该是100m的ddr，不算很高的速率，理论上是不用手动调整的，我有点怀疑你们用的代码或者硬件有点问题？

TUJzzz

拾冠 发表于 2023-8-2 08:57
The tuning may be done either in FPGA, AD9361 or both (though not necessary). The FPGA tuning may be ...

    感谢您的回复。
    真是闹了一个笑话，我居然无视了这么明显的一段话。
    之前9361打回来的data_clk是100M，现在是200M的，其实之前也有时序问题，但是没判断出来（表现为底噪有时会有一个特别高的点），data_clk变为200M后时序错乱了，经过调整后时序正常了。目前我也没有其他方法去判断软件或者硬件还存在什么其他问题，先准备就这样先放着，看后续调试会不会出现问题。
    官方邮件回复了我的疑惑，第一个问题他们的回答是，驱动初始化9361的基地址不一样，看来不涉及sync_in脉冲的相位（之前会认为sync_in可能需要跟master9361的时钟相位一致），那看来随便哪个9361设为master9361都可以。
    第二个问题，回复了让我去看UG-570的88页，但是88页的八个步骤完全没提到重设delay参数的过程，也没法再问了（qq邮箱回复不了官方地址，邮件会被退回）。
    关于PRBS校验，我可以用官方驱动的校验模块（axi_ad9361_rx_pnmon.v）成功校验9361发回来的PRBS序列（oos拉低），但是我从《AD9361BISTFAQ.pdf》中获得的代码，却没办法通过axi_ad9361_rx_pnmon.v的校验，做这个的主要目的是想用PRBS回环验证TX通路的时序，不知道您是否尝试过类似的东西。

AD9361BISTFAQ.pdf (515.04 KB, 下载次数: 12 )

2023-8-2 12:35 上传

点击文件名下载附件

拾冠

你们用的2r2t的格式的话确实是200m的ddr，可能需要调整接口时序。这个东西一时半会也讲不了。我们自己用的一直是1r1t，所以没调过。
我的建议有几个：
1.9361的同步只是bbpll同步，rf的同步是无法实现的，所以我推测你们的同步需求没那么高，即使寄存器真的影响data_clk的输出延迟也没关系，只是最后同步完会看到几个9361芯片输出的data_clk相位不一致。也可以先不管时序，先做同步看看data_clk的相位是否同步。
2.判断一下时序是否真的有问题，可以了解一下prbs的生成格式，然后根据收回来的数据分析一下是否有错误情况发生。有时可能真的硬件有干扰，误判成时序造成的毛刺。

TUJzzz

拾冠 发表于 2023-8-2 13:58
你们用的2r2t的格式的话确实是200m的ddr，可能需要调整接口时序。这个东西一时半会也讲不了。我们自己用的 ...

确实说到点子上了，这是中途接手的项目（各方人员都离职了一轮），感觉确实同步要求不高，MCS这功能做不做影响不大。接收通路的PRBS校验是通过了的；发送通路因为我上个回复中提的问题，所以没用PRBS校验，发了个正弦波，回环收回来看是否光滑。总体来说，接口现在在只调整9361的情况下时序正常了（偏维护性质，能用就行），只是担心我在驱动函数中注释的那部分代码会给项目留下隐患，不过目前看下来比较稳定，多次测试没有再出现时序错乱的情况。

FPGA侧调整的方案，准备把他当作个预留方案，确实感觉延迟处理放在FPGA内部比较合适。
感谢您的指导回复