[Discuss OpenCPI] OCPI Assembly Selection

Miller, Peter PeterM at signalscape.com
Wed Jun 20 08:31:53 EDT 2018


Can you provide an example of how to specify a particular assembly and container for that assembly to be used to run an ACI? If one modifies an HDL worker then to run/debug it one has to rebuild the worker and the assembly and run the ACI. OCPI_LIBRARY_PATH lets me specify an assembly folder so I only need to wait for that assembly to build, not every possible one that could work.

-----Original Message-----
From: discuss <discuss-bounces at lists.opencpi.org> On Behalf Of James Kulp
Sent: Wednesday, June 20, 2018 7:43 AM
To: discuss at lists.opencpi.org
Subject: Re: [Discuss OpenCPI] OCPI Assembly Selection

Hi Peter,

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.

Jim


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).
>
> DETAILS
> 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.wifip
> roject/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
>
> ./target-linux-c7-x86_64/phy_tx_802dot11g_app
>
> Sincerely,
> 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/attachme
> nts/20180620/c7b2c8ba/attachment.html>
> _______________________________________________
> discuss mailing list
> discuss at lists.opencpi.org
> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org



_______________________________________________
discuss mailing list
discuss at lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
--------------------------- 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.



More information about the discuss mailing list