The goal of this guide is to use the SSI Loopback functionality from Tx1 to Rx1 to verify that data is reaching the Tx1 interface without being corrupted. This guide is quite useful of people who have evaluated the ADRV9001 product and are now attempting to build their own platform away from the ZC706 FPGA. The following steps should be carried out first using our FPGA platform and then ported over to their own platform if the FPGA run is successful.
In the User Guide, under Data Interface: CSSI/LSSI Testability and Debug there is the following diagram. The loopback which has been circled in Red is the one we intend to use here.
Step 1:Set your Configurations tab
For this example, an FDD setup will be used, as shown below. Any setup which allows the Rx1 interface to send data while the Tx1 datapath is transmitting is acceptable, meaning that not all TDD setups will allow this test to run. Additionally, no tracking calibration that requires Internal Loopback or External Loopback can be used. As we’re enabling the SSI loopback, no data will reach the Rx SSI via the Rx datapath.
The Dual Channel operation will be required for this debug operation. We’re going to program the Tx1 channel to perform various transmissions and then monitor the output using both the Rx1 interface and a Spectrum Analyzer. The same steps would also work for Tx2 -> Rx2 under different setups. The only major change will be to the set_Loopback(…) command, we’ll highlight this later.
Step 2: Set the Carriers tab
The only alteration made to this setup was to change the Tx Carrier Frequency to 1.6GHz. Do also run a quick check of all other tabs, the default configurations for this setup are fine so no edits are made here. One configuration that will be required is the Tx Data Source being set to the FPGA in the Radio tab. Using internal tone generation will power down the Tx SSI, which will prevent us from performing this test.
Having an IF set for the Rx1 channel will not affect this test at all, as there will be no mixing taking place. Any legal carrier frequency that you want to test here will work, 1.6GHz is just one usecase.
Step 3: Program the part
At this point it’s no harm to quickly test the Tx transmission using the spectrum analyser as a sanity check:
At this point we can set the SSI Loopback. If you try receiving data now you should observe nothing on Rx1 or Rx2:
Step 4: Set the SSI Loopback
Stop all Tx and Rx operation. Now open the IronPython programming interface and load the SSI_Loopback.py script (it has been supplied with this guide in .zip format). Pay particular attention to the areas of code circled in red in the below images. These are the sections of code added to the default “New File.py” that opens when the IronPython coding interface is opened.
If everything runs as expected you should see “Loopback Set” printed into the terminal window. *Note: For setups which allow Tx2 -> Rx2 loopback, we can change the “channel_num = common_ChannelNumber_e(1)” line to “channel_num = common_ChannelNumber_e(2)”. The channel type can similarly be changed from CMOS: “channel_type = adrv9001_SsiType_e(1)”, to LVDS: “channel_type = adrv9001_SsiType_e(2)”
Step 5: Program the Part Again
Start transmitting again. The spectrum analyser should see exactly the same thing as before:
Now start receiving while transmitting:
Notice how Rx1 (in Black) now sees exactly the same tone that’s present in the Tx tab. Deselect Rx2 (the Blue line) in this tab now.
If we start changing the transmission, Rx1 should respond accordingly:
At this point we’ve confirmed that data is reaching the Tx1 dataport through the FPGA without distortion.
Step 6: Produce C code and Compile on Platform
Produce C code from this session using Sample Code -> C99. It’s unlikely that the API we called in the IronPython interface has been saved into the log file, so we’ll need to find the correct point to insert it. The loopback must be set in the Primed state after all calibrations are complete, but before the device enters the RF Enabled state. Navigate to your C code and open the main.c file:
We’re going to add 1 extra #include and call the SSI Loopback API between the “prime(…)” call and the “beginReceiving(…)” call:
The arguments for the API are identical to those we used in the IronPython interface:
- A pointer to the ADRV9001 device (Not used in IronPython)
- Channel Number: 1 = Channel 1, 2 = Channel 2
- Channel Type: 1 = CMOS, 2 = LVDS
- Loopback Enable: 0 = False, 1 = True
Next, we will compile this code on your own platform. You will need to adjust the generated C code to suit your platform. Get the code to compile on your platform before proceeding.
Step 7: Confirm RF performance on Platform
We’ll simply perform step 5 again. Transmit data to a spectrum analyzer. Confirm that it matches your expectations, and then inspect the data returned from the Rx1 datapath. That may have to be done offline, but that’s fine.
What you’re looking for is any glaring differences between the Tx1 input data and the Rx1 output data. Any differences here would indicate strongly that the Tx1 SSI has not been setup correctly on your own platform. Things to look out for are:
- Reduced SNR
- Increased / Decreased Tx signal bandwidth
- The Tx Tone being at completely the wrong frequency
- A Tx tone that moves when it shouldn’t
Step 8: Extra Debug (if needed)
Pending the results of the previous 7 steps, you may or may not have narrowed down the possible causes for your issue. If you’re still having issues the following considerations may help you home in on the problems you are experiencing. These considerations will go into how you have configured the Tx/Rx SSI ports on your own platform. If you monitor your SSI port during its interactions and the behavior does not match your expectations we will have found the source of the issue.
- Rx SSI
In CMOS-DDR mode, with default SSI configuration:
Navassa RX SSI output should be something like Figure1;
Ps: Yellow - Clock, Purple – Strobe, Green – Data
Figure 1: CSSI-DDR default, Navassa Rx SSI output
‘cmosDdrClkInversionEn’ doesn’t help on the SSI setup/hold time for DDR mode, it only effects on which clock edge (rising or falling) the system will sample the first strobe/data, refer Figure 2.
Figure 2: CSSI-DDR default -> set cmosDdrClkInversionEn = True
‘cmosDdrPosClkEn’ = True will add a quarter clock delay (refer Figure 3) but as Figure 1 shows Rx SSI clock output by default has quarter clock delay to strobe/data. So, another quarter clock delay will make the clock/strobe/data phase aligned.
Figure 3: CSSI-DDR default -> set cmosDdrPosClkEn = True
- TX SSI
- Tx SSI clock/Strobe/Data is controlled by users’ BBP, they should make sure the SSI setup/hold time at ADRV9002 SSI pad inputs meet the spec requirement.
- “cmosTxDdrNegStrobeEn” is internal debug and Tx SSI only, users don’t need to change the default value.
- cmosDdrPosClkEn and cmosDdrClkInversionEn have the same functions as their Rx SSI counterparts, they can set cmosDdrPosClkEn = Ture to make a quarter clock delay and check if it helps
- Another useful check is to call the “adi_adrv9001_Ssi_Delay_Configure” to set the clock/strobe/data phase relationship in ADRV9002.
