Suggests running some commands in the terminal for more documentation.
In terminal, in ocpi.osps.e3xx/applications/FSK directory:
export OCPI_CDK_DIR=/home/<user>/Documents/opencpi/cdk
make show
Instructions then appear in terminal.
Suggests four steps for executing a test application:
1) Build ACI and/or input test data (development system)
2) Setup the OCPI_LIBRARY_PATH (remote system)
3) Execution of application (remote system)
4) Verification of output data (development system)
According to make show described above this builds input data, ACI executable and filter coeffecients.
cd into /opencpi/projects/osps/ocpi.osp.e3xx/applications/fsk_dig_radio_ctrlr
ocpidev build --rcc-platform xilinx19_2_aarch32
I execute this command and target-xilinx19_2_aarch32 folder is created with <fsk_dig_radio_ctrlr, fsk_dig_radio_ctrlr.o, fsk_dig_radio_ctrlr.o.deps>
ocpidev build --rcc-platform xilinx19_2_aarch32 (xilinx13_3 used in the example). As above.
This is just a comment that the build command is also expressed in this section of FSK_app.
Adam suggests that the fsk_modem needs to be build in the e3xx project not the assets project.
Aaron mentions HDL assembly for e31x needs to be built. This needs to be done in projects/osps/ocpi.osp.e3xx/hdl/assemblies/fsk_modem folder using:
ocpidev build --hdl-platform e31x
I am unsure what this does but executing the command doesn't return any errors.
If the OCPI_LIBRARY_PATH isn't set correctly there is usually an error so it's assumed that the library paths are correct when I'm running the test application.
Path used is
export OCPI_LIBRARY_PATH=/mnt/ocpi_assets/artifacts:/mnt/ocpi_core/artifacts:/mnt/ocpi_e31x/artifacts:/mnt/ocpi_assets/hdl/assemblies/fsk_modem:/mnt/ocpi_core/hdl/assemblies/fsk_modem:/mnt/ocpi_e31x/hdl/assemblies/fsk_modem/
which produces no errors with the ocpirun -x -t 15 fsk_modem_app.xml command.
Initial questions:
What should OCPI_LIBRARY_PATH be set to? Does each platform have a suggested OCPI_LIBRARY_PATH?
Does it matter where the OCPI_LIBRARY_PATH command is ran? Only seems to matter if relative paths are used.
Some doc. examples use export OCPI_LIBRARY_PATH, some use just use OCPI_LIBRARY_PATH (FSK_app, Section 5.6). Assumption is that 'export' is required, recommended paths are just stated as the path not the actual command.
Mentions going to OpenCPI Application Development Guide for information about OCPI_LIBRARY_PATH.
Last parapgraph has some comments about OPCI_LIBRARY_PATH that are critical. Too much information to copy to here. It does mention that the order of the OCPI_LIBRARY_PATH list is important.
If using a platform with multiple slots available, the intended slot-specific bitstream must occur first in the OCPI_LIBRARY_PATH. This similar to explaination in OpenCPI Application Development Guide, Section 2, Page 8.
make show instructions from FSK application directory suggested OCPI_LIBRARY_PATH(s):
Test 1:
export OCPI_LIBRARY_PATH=$(pwd)/../../artifacts:/mnt/ocpi_core/artifacts:/mnt/ocpi_assets/artifacts
Test 2:
export OCPI_LIBRARY_PATH=$(pwd)/../../artifacts/ocpi.osp.e3xx.dc_offset_iq_imbalance_mixer_cic_dec_rp_cordic_fir_real_e31x_cfg_1rx_0tx_mode_2_cmos_cnt_1rx_0tx_thruasm_mode_2_cmos_e31x.hdl.0.e31x.gz:$OCPI_LIBRARY_PATH
Test 3:
export OCPI_LIBRARY_PATH=$(pwd)/../../artifacts/ocpi.osp.e3xx.mfsk2_zp16_fir_real_phase_to_amp_cordic_cic_int_e31x_cfg_0rx_1tx_mode_2_cmos_cnt_0rx_1tx_thruasm_mode_2_cmos_e31x.hdl.0.e31x.gz:$OCPI_LIBRARY_PATH
Test 4:
export OCPI_LIBRARY_PATH=$(pwd)/../../artifacts/ocpi.osp.e3xx.fsk_modem_e31x_cfg_1rx_1tx_mode_2_cmos_cnt_1rx_1tx_thruasm_mode_2_cmos_e31x.hdl.0.e31x.gz:$OCPI_LIBRARY_PATH
I assume :$OCPI_LIBRARY_PATH is done for the slot-specific bitstream reasoning mentioned in FSK_Dig_Radio_Ctrlr, Section 3.1.
For the Zed with fmcomms2 he used:
export OCPI_LIBRARY_PATH=/mnt/ocpi_assets/hdl/assemblies/fsk_modem:/mnt/ocpi_core/artifacts:/mnt/ocpi_assets/artifacts
but suggested to use for the e310:
export OCPI_LIBRARY_PATH=/mnt/ocpi_e31x/hdl/assemblies/fsk_modem:/mnt/ocpi_core/artifacts:/mnt/ocpi_assets/artifacts
Trying both exports individually end with an error after doing ocpirun -v -x -t 15 fsk_modem_app.xml:
Exiting for exception: No acceptable implementations found in any libraries for "ocpi.platform.drc". Use log level 8 for more detail.
This section suggests using:
$ export OCPI_LIBRARY_PATH=/mnt/net/cdk/xilinx19_2_aarch32/artifacts:/mnt/ocpi_assets/applications/FSK/../../hdl/assemblies/fsk_modem:/mnt/ocpi_assets/applications/FSK/../../artifacts
This doesn't really make sense, why not just use /mnt/ocpi_assets/artifacts and /mnt/ocpi_assets/hdl/assemblies/fsk_modem?
Adding :/mnt/net/cdk/xilinx19_2_aarch32/artifacts to my library path doesn't change the result of the ocpirun command.
The following assets are built and their build artifacts (FPGA bitstream file/shared object file) are contained within the directory list of the OCPI_LIBRARY_PATH environment variable.
–fsk_filerw assembly
–fsk_modem assembly (from assets project, or same assembly XML w/ another BSP-specific container XML in another BSP-specific project)
–file_read.rcc (from core project)
–mfsk_mapper.rcc–zero_pad.rcc
–Baudtracking_simple.rcc
–real_digitizer.rcc
–file_write.rcc (from core project)
"By limiting the artifacts available (accessed via the OCPI_LIBRARY_PATH environment variable setting), the system requirements are reduced to the minimum."
This section has a list of artifacts required for the e31x application.
Also mentions:
"Each required RCC worker corresponds to a required target-<shortened-rcc-platform>/<worker>.so artifact. All required HDL workers (together) correspond to a single required <assembly><platform><platform-config><container>.bitz artifact."
Does that mean that for each platform only 2 OCPI_LIBRARY_PATHs need to be specified, one to target-<shortened-rcc-platform>/<worker>.so and one to <assembly><platform><platform-config><container>.bitz?
ie.
/mnt/ocpi_e31x/applications/fsk_dig_radio_ctrlr/target-xilinx19_2_aarch32
and
/mnt/ocpi_e31x/exports/artifacts
Running just these two OCPI_LIBRARY_PATHs gives below error:
Available containers are: 0: PL:0 [model: hdl os: platform: e31x], 1: rcc0 [model: rcc os: linux platform: xilinx19_2_aarch32]
Exiting for exception: No acceptable implementations found in any libraries for "ocpi.core.file_read". Use log level 8 for more detail.
Look in this section for arguments for the FSK application. This sets the Ettus internal parameters (ie. gain, RX/TX port used).
Arguments are given in this section for the FMCOMMS2 and the FMCOMMS3. These could be used to compare with the Ettus arguments in FSK_App_E31x, Section 5.3.
In opencpi/projects/osps/ocpi.osp.e3xx/applications/fsk_dig_radio_ctrlr/scripts/fsk_dig_radio_ctrl_demo_txrx_sma_loopback_xilinx13_4_e31x.sh there is a command:
OCPI_HDL_SIMULATORS= \
OCPI_LIBRARY_PATH=/mnt/ocpi_assets/artifacts/:/mnt/ocpi_core/artifacts/:/mnt/osps/ocpi.osp.e3xx/artifacts \
./target-xilinx13_4/fsk_dig_radio_ctrlr \
--rx-data-stream-ID SMA_RX2A \
--rx-baud-rate 5699 \
--rx-tuning-freq-MHz 2450 \
--rx-gain-mode manual \
--rx-gain-dB 12 \
--tolerance-rx-tuning-freq-MHz 0.1 \
--tolerance-rx-gain-dB 1 \
--tx-data-stream-ID SMA_TRXA \
--tx-baud-rate 5699 \
--tx-tuning-freq-MHz 2450 \
--tx-gain-mode manual \
--tx-gain-dB -28 \
--tolerance-tx-tuning-freq-MHz 0.1 \
--tolerance-tx-gain-dB 1 -d\
fsk_dig_radio_ctrlr_e31x_txrx.xml
Executing above (with -l 8 and xilinx13_4 = xilinx19_2_aarch32) gives the error:
OCPI( 8:951.0262): Rejected: worker name is "dig_radio_ctrlr_fmcomms_2_3-1.rcc", while requested worker name is "dig_radio_ctrlr_e31x"
OCPI( 8:951.0262): Error Exception: No acceptable implementations found in any libraries for "ocpi.core.dig_radio_ctrlr". Use log level 8 for more detail.
Exiting for exception: No acceptable implementations found in any libraries for "ocpi.core.dig_radio_ctrlr". Use log level 8 for more detail.
Same path as above with different script.
OCPI_HDL_SIMULATORS= \
OCPI_LIBRARY_PATH=/mnt/ocpi_assets/artifacts/:/mnt/ocpi_core/artifacts/:/mnt/osps/ocpi.osp.e3xx/artifacts \
./target-xilinx13_4/fsk_dig_radio_ctrlr \
--tx-data-stream-ID SMA_TRXA \
--tx-baud-rate 5699 \
--tx-tuning-freq-MHz 2450 \
--tx-gain-mode manual \
--tx-gain-dB -28 \
--tolerance-tx-tuning-freq-MHz 0.1 \
--tolerance-tx-gain-dB 1 -d\
fsk_dig_radio_ctrlr_e31x_tx.xml
I didn't run this as the former script seemed more complete.
This describes how to physically setup the Ettus and what the different tests do. The txrx test mentions that the gain setting assumes that an RF splitter will be used. RF splitter was used for my tests so gain should be correct.
The input file has a 0xFACE prepended byte pattern. Running the .xml mentions that it detects this value. It also mentions "Since this test is executed for a duration, rather than total image recognition, it is not uncommon that the output file will be larger than the actual size of the input image". This has also been seen in practice.
The FSK application directory has been replaced with fsk_dig_radio_controller. We are in the processes of removing legacy applications. To run the fsk_modem_app.xml the e31x and xilinx19_2_aarch32
platform depend on ocpi.core, ocpi.assets, ocpi.platform, and ocpi.osp.e31x projects.
$ ./target-xilinx13_3/FSK txrx
Does ./target-xilinx19_2_aarch32/fsk_dig_radio_ctrlr txrx need to be called? Or something similar? Why is there a method of using the .target directory and a method for using the .xml for running the application?
ocpirun -v -d -x -t 15 fsk_modem_app.xml
which runs the application fine.
cd assets/applications/fsk_dig_radio_ctrlr
eog fsk_dig_radio_ctrlr_fmcomms_2_3_txrx.bin
Note that the fsk_modem_app.xml writes to fsk_dig_radio_ctrlr_fmcomms_2_3_txrx.bin. Shouldn't it write to fsk_dig_radio_ctrlr_e31x_txrx.bin or equivalent?
"The demodulation algorithm currently suffers from limited carrier recovery ability which can cause the output image to be corrupted or non-existent when using the txrx mode. If using an SMA loopback for txrx mode on a RF transceiver where the RX and TX data stream’s LOs are sourced by the same clock (which is the case on FMCOMMS2/3), carrier recovery is not expected to be an issue."
Note that the Ettus RX LO and TX LO are different clocks so this is potentially an issue.
"The rx and tx modes suffer from limited carrier recovery ability. The requested center frequency may need to be adjusted to a value other than the exact expected nominal value."
"Sometimes the radio can get into an unwanted state. If unusual results are seen, run ocpihdl unload and rerun the application."
Note that ocpihdl unload doesn't work and returns the following error:
fpga_manager fpga0: Invalid bitstream, could not find a sync word. Bitstream must be a byte swapped .bin file
fpga_manager fpga0: Error preparing FPGA for writing
Doesn't explicitly mention xilinx19_2_aarch32 or e31x are supported hardware configurations but the last dot point suggests it may work.
Up to 10 MS/s sample data transfer rate to ARM processor. This is between the PS-Dual Core ARM and the PL-FPGA.
Is this limiting the data rate of the transmitted signal?
Workstation PC ethernet port only capable of 1 Gbps. Shouldn't be a problem as the signals bandwidth is less than 5 MHz.