[Discuss OpenCPI] OCPI Assembly Selection

Miller, Peter PeterM at signalscape.com
Wed Jun 20 07:11:37 EDT 2018

I believe I am experiencing a pitfall that Adam P. described during training months ago. I'm not sure if I'm reporting a problem or reporting incompetence, but a novice user likely experience this and hours are spent chasing it down. Perhaps there needs to be some improvement (ocpidev; the gui) to require the intended assembly be specified when more than one is found can hook up. And grepping the LOG_LEVEL=8 output is a hard sell. Either that or some super-touch tool to cause all affected assemblies to be rebuilt when a worker is modified (imagine the time that would take).

When running an application ACI if I specify:
export OCPI_LIBRARY_PATH=$OCPI_LIBRARY_PATH:/home/pbmiller/SS_SDR/Frameworks/ocpi.wifiproject/exports
Then I get the first assembly that hooks up. I did not know that the search path would include assemblies built for unit testing (but it makes sense). The situation is this:

  1.  Created a component/worker called transmitter/phy_tx_802dot11g.hdl and a unit tester transmitter/phy_tx_802dot11g.test. The test drives the transmitter with one data file and generates one output file of iqsamples.
  2.  To test in more real scenario we created an application "phy_tx_802dot11g_app" and an assembly "phy_tx_802dot11g_assy" with only the phy_tx_802dot11g.hdl" worker in it. This app sends multiple data frames and generates multiple bursts to a sample file.
  3.  To test further we want to build the "phy_tx_802dot11g_assy" for both the base container and for the zed+fmcomms3 container. (see thread with Jim K.)
Had all three above working and then made a modification to the transmitter worker. To test step 2 again I cleaned the phy_tx_802dot11g_assy and rebuilt the worker, then the assembly, and ran the app. Nothing changed. So running the app with OCPI_LOG_LEVEL=8, I see:
OCPI( 8:516.0936): Successfully loaded bitstream file: "/home/pbmiller/SS_SDR/Frameworks/ocpi.core/exports/imports/ocpi.wifiproject/components/transmitter/phy_tx_802dot11g.test/gen/assemblies/phy_tx_802dot11g_0/container-phy_tx_802dot11g_0_xsim_base/target-xsim/phy_tx_802dot11g_0_xsim_base.tar.gz" for simulation

So the application is choosing the assembly from the unit tester rather than the intended one because the OCPI_LIBRARY_PATH was not specific enough. Doing the following fixes the problem:

export OCPI_LIBRARY_PATH=$OCPI_LIBRARY_PATH:/home/pbmiller/SS_SDR/Frameworks/ocpi.wifiprojects/exports:/home/pbmiller/SS_SDR/Waveforms/Ieee802dot11/ocpi.wifiproject/hdl/assemblies/phy_tx_802dot11g_assy


Peter B. Miller
Potomac: (301) 765-9668

--------------------------- This email and any files transmitted with it are confidential and intended solely for the use of Signalscape, Inc. and the addressed individual or entity. If you have received this email in error please delete it. Information in this email may be subject to the Privacy Act of 1974 and any unauthorized review, use, disclosure, or distribution is strictly prohibited. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attachments/20180620/c7b2c8ba/attachment.html>

More information about the discuss mailing list