[Discuss OpenCPI] OCPI Assembly Selection
jek at parera.com
Wed Jun 20 07:43:10 EDT 2018
There are a number of ways to narrow down the search for usable
artifacts that satisfy the application.
OCPI_LIBRARY_PATH is probably the worst, but it is effective.
For any instance in the application you can constrain it (either in the
ACI or as command line options to ocpirun) several ways:
-m (ocpirun) or "model" (ACI) can force something to rcc or hdl
-P (ocpirun) or "platform" (ACI) can force something to a particular
platform (xilinx13_3, zed, xsim, etc.).
-c (ocpirun) or "container" (ACI) to put the instance on a particular
container by number or name
-s (ocpirun) or "selection" (ACI) to use a selection expression based on
parameter values and some built-in values like "model"
-w (ocpirun) or "worker" (ACI) to identify a particular worker to use
for the instance (independent of platform or container).
All of these can apply to one instance or all instances (e.g. -m=hdl for
all instances to hdl, vs. -mmyfir=hdl to force myfir to hdl).
Also, you can specify all instanced to one model (or anything) and then
specific instances to another)
(e.g. -m=rcc -mmyfir=hdl).
The unit test system automatically iterates through test cases by
changing the "platform" and the "worker" across all test cases.
On 6/20/18 7:11 AM, Miller, Peter wrote:
> 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>
> discuss mailing list
> discuss at lists.opencpi.org
More information about the discuss