I believe I am experiencing as pitfall that Adam P. described during training months ago. export OCPI_LIBRARY_PATH=$OCPI_LIBRARY_PATH:/home/pbmiller/SS_SDR/Frameworks/ocpi.core/exports 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 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.

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.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 ./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.

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.)

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.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 > > ./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. >

One other item: The ocpirun -v flag (or "verbose" in the ACI) will always tell you the deployment (which artifacts/platforms/containers), with out extra log levels. On 6/20/18 6:23 AM, Miller, Peter wrote: > I believe I am experiencing as pitfall that Adam P. described during training months ago. > > > > export OCPI_LIBRARY_PATH=$OCPI_LIBRARY_PATH:/home/pbmiller/SS_SDR/Frameworks/ocpi.core/exports > 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 > > > > 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. >

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"

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@lists.opencpi.org> On Behalf Of James Kulp Sent: Wednesday, June 20, 2018 7:43 AM To: discuss@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@lists.opencpi.org > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org _______________________________________________ discuss mailing list discuss@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.

 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"

All the options I described were for specifying constraints for instances in the application at execution time. These constraints limit the artifacts considered for use and/or limit the runtime containers that will be used. This "runtime" side has nothing to do with building - just looking at available artifacts to be considered for use. You can (re)build individual assemblies as you want and the new one will be considered during execution. If the per-instance options I described are insufficient to narrow down the deployment you need,  specifying the directory in OCPI_LIBRARY_PATH (or even the precise artifact), can very explicitly get you what you want, but it is usually overly specific and more cumbersome. OpenCPI does have an unfortunate terminology problem with overloading the term "container". At execution time, in ocpirun or ACI, we use the term "container" to be a particular place to run artifacts consisting of workers - a runtime environment on an instance of a platform. (a particular FPGA or processor). When building artifacts for FPGAs, we use the term "container" to be a particular mapping of an assembly on a platform (not an instance of a platform but a type of platform). So with an ACI program, you can either set the OCPI_LIBRARY_PATH outside the executable (exported or on its command line), or inside the executable using setenv/putenv POSIX APIs. In the case you described, using -P selects which platform to use, but to distinguish between zed->file_write from zed->dac, you would use a different application XML (one with the dac worker there). On 6/20/18 8:31 AM, Miller, Peter wrote: > 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@lists.opencpi.org> On Behalf Of James Kulp > Sent: Wednesday, June 20, 2018 7:43 AM > To: discuss@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@lists.opencpi.org >> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > > > _______________________________________________ > discuss mailing list > discuss@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. > > _______________________________________________ > discuss mailing list > discuss@lists.opencpi.org > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org