Hi,
I've recently experienced an issue when testing prebuilt and custom FPGA/Linux builds for AD9081<->VCU118 whereby not all the NCOs can be controlled via PyADI.
vcu118_ad9081_204c_txmode_23_rxmode_25_lr_24_75Gbps
I flashed a prebuilt vcu118_ad9081_204c_txmode_23_rxmode_25_lr_24_75Gbps image to the device and ran the following test in Python shell:
>>> import adi
>>> dev = adi.ad9081("ip:192.168.0.66")
>>> dev.tx_main_nco_frequencies = [0] * 1
>>> dev.tx_main_nco_frequencies = [0] * 2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\[User]\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\adi\ad9081.py", line 456, in tx_main_nco_frequencies
self._set_iio_attr_int_vec(
File "C:\Users\[User]\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\adi\attribute.py", line 132, in _set_iio_attr_int_vec
self._set_iio_attr_int(channel_names[i], attr_name, output, v, _ctrl)
IndexError: list index out of range
>>> dev.rx_main_nco_frequencies = [0] * 2
>>> dev.dds_single_tone(100e6, 0.1, channel=0)
>>> dev.dds_single_tone(100e6, 0.1, channel=1)
>>> dev.dds_single_tone(100e6, 0.1, channel=2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\[User]\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\adi\dds.py", line 174, in dds_single_tone
chan.attrs["frequency"].value = str(frequency)
AttributeError: 'NoneType' object has no attribute 'attrs'
>>>
You can see that only 1off NCO can be set for the DAC, whereas 2off NCOs can be set for the ADC and 2off DDS channels can be set. As this is an M=4 design, shouldn't both NCOs be controllable?
I operated the build in IIO-Oscilloscope and found that both channels and their NCOs could be operated as demonstrated above.
vcu118_ad9081_204c_txmode_24_rxmode_26_lr_24_75Gbps
I repeated the above for vcu118_ad9081_204c_txmode_24_rxmode_26_lr_24_75Gbps and found similar behaviour:
>>> import adi
>>> dev = adi.ad9081("ip:192.168.0.66")
>>> dev.tx_main_nco_frequencies = [0] * 2
>>> dev.tx_main_nco_frequencies = [0] * 3
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\[USER]\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\adi\ad9081.py", line 456, in tx_main_nco_frequencies
self._set_iio_attr_int_vec(
File "C:\Users[USER]\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\adi\attribute.py", line 132, in _set_iio_attr_int_vec
self._set_iio_attr_int(channel_names[i], attr_name, output, v, _ctrl)
IndexError: list index out of range
>>> dev.rx_main_nco_frequencies = [0] * 4
>>> dev.dds_single_tone(100e6, 0.1, channel=0)
>>> dev.dds_single_tone(100e6, 0.1, channel=1)
>>> dev.dds_single_tone(100e6, 0.1, channel=2)
>>> dev.dds_single_tone(100e6, 0.1, channel=3)
Again, all ADC/Rx NCOs could be operated in PyADI and IIO-'Scope; however, only 2 out of 4 DAC/Tx NCOs could be operated in PyADI and in IIO-'Scope.
I couldn't enable DAC channels 2 and 3 in IIO-'Scope this time.
I looked into the device trees of the two build to try and understand why and saw that for vcu118_ad9081_204c_txmode_24_rxmode_26_lr_24_75Gbps (linux/arch/microblaze/boot/dts/vcu118_ad9081_204c_txmode_24_rxmode_26_lr_24_75Gbps.dts at master · analogdevicesinc/linux · GitHub), the link modes were not specified as expected:
adi,jesd-links {
#size-cells = <0>;
#address-cells = <1>;
ad9081_tx_jesd_l0: link@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
adi,logical-lane-mapping = /bits/ 8 <0 2 7 6 1 5 4 3>;
adi,link-mode = <23>; /* JESD Quick Configuration Mode */
adi,subclass = <1>; /* JESD SUBCLASS 0,1,2 */
adi,version = <2>; /* JESD VERSION 0=204A,1=204B,2=204C */
adi,dual-link = <0>; /* JESD Dual Link Mode */
adi,converters-per-device = <8>; /* JESD M */
adi,octets-per-frame = <3>; /* JESD F */
adi,frames-per-multiframe = <256>; /* JESD K */
adi,converter-resolution = <12>; /* JESD N */
adi,bits-per-sample = <12>; /* JESD NP' */
adi,control-bits-per-sample = <0>; /* JESD CS */
adi,lanes-per-device = <8>; /* JESD L */
adi,samples-per-converter-per-frame = <2>; /* JESD S */
adi,high-density = <1>; /* JESD HD */
adi,tpl-phase-adjust = <0x3b>;
};
};
adi,jesd-links {
#size-cells = <0>;
#address-cells = <1>;
ad9081_rx_jesd_l0: link@0 {
reg = <0>;
adi,converter-select =
<&ad9081_rx_fddc_chan0 FDDC_I>, <&ad9081_rx_fddc_chan0 FDDC_Q>,
<&ad9081_rx_fddc_chan1 FDDC_I>, <&ad9081_rx_fddc_chan1 FDDC_Q>,
<&ad9081_rx_fddc_chan4 FDDC_I>, <&ad9081_rx_fddc_chan4 FDDC_Q>,
<&ad9081_rx_fddc_chan5 FDDC_I>, <&ad9081_rx_fddc_chan5 FDDC_Q>;
adi,logical-lane-mapping = /bits/ 8 <2 0 7 6 5 4 3 1>;
adi,link-mode = <25>; /* JESD Quick Configuration Mode */
adi,subclass = <1>; /* JESD SUBCLASS 0,1,2 */
adi,version = <2>; /* JESD VERSION 0=204A,1=204B,2=204C */
adi,dual-link = <0>; /* JESD Dual Link Mode */
adi,converters-per-device = <8>; /* JESD M */
adi,octets-per-frame = <3>; /* JESD F */
adi,frames-per-multiframe = <256>; /* JESD K */
adi,converter-resolution = <12>; /* JESD N */
adi,bits-per-sample = <12>; /* JESD NP' */
adi,control-bits-per-sample = <0>; /* JESD CS */
adi,lanes-per-device = <8>; /* JESD L */
adi,samples-per-converter-per-frame = <2>; /* JESD S */
adi,high-density = <1>; /* JESD HD */
};
};
However, the vcu118_ad9081_204c_txmode_23_rxmode_25_lr_24_75Gbps build's dts looks fine and that experiences a similar issue. Furthermore, some custom build I've tried running also experience this issue on DAC and ADC sides despite the .dts looking okay.
As far as I can see, from cross-referencing with AD9081/AD9082 Software Development User Guide, UG-1578 (Rev. A) (analog.com), the actual LMFSK specifications look okay.
Can you please tell me (a) what is limiting the control of the NCOs when using PyADI and (b) what impact, if any, a incorrectly specified adi,link-mode would have if LMFSK is specified correctly?
Thanks,
Deng
