Suppose I create a simple hdl assembly that contains one component, phy_tx_802dot11g.hdl.
ocpidev create hdl assembly phy_tx_802dot11g_assy

ocpidev build hdl assembly phy_tx_802dot11g_assy --hdl-platform xsim --hdl-platform zed

hdl/assemblies/phy_tx_802dot11g_assy/container-phy_tx_802dot11g_assy_xsim_base
hdl/assemblies/phy_tx_802dot11g_assy/container-phy_tx_802dot11g_assy_zed_base

I can use this assembly to create an application that, say, connects to file_write and I can run it on Centos or Zed. Now I want to make an application that connects it to qdac on the zed fmcomms3. I copy the container file "cnt_1rx_1tx_thruasm_fmcomms_2_3_lpc_LVDS_zed.xml" and modify the Makefile to add "Containers=cnt_1rx_1tx_thruasm_fmcomms_2_3_lpc_LVDS_zed" and build.
hdl/assemblies/phy_tx_802dot11g_assy/container-phy_tx_802dot11g_assy_zed__cfg_1rx_1tx_fmcomms_2_3_lpc_lvds_cnt_1rx_1tx_thruasm_fmcomms_2_3_lpc_LVDS_zed

Now a make clean and make only generates the fmcomm container and not the base.

Question: How can I modify the makefile to specify a container for the Base container? Such that make clean, make will build the base and the config folders? Is there a "Containers=" for the base assembly?

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.

Hi Peter,

It is true that nothing in container-* should be modified since it is
all generated and cleaned.
When you are creating a non-default container (one that has interesting
connections or non-default platform configuration),
you put the container XML file in the assembly's directory and mention
it in the Containers= variable in the Makefile.
In that container XML you specifiy what is "not default" about the
container, any of:

1. Device connections of external ports of the assembly
2. Device presence (possibly parameterized) when not implied by device
   connections or platform configuration
3. The Platform Configuration to use (thus implying the presence of
   devices or cards).
   The container file you copied has a specifically indicated platform
   configuration.
   You probably just need to change the platform configuration indicated
   there to "base".

Jim

On 6/19/18 8:58 AM, Miller, Peter wrote:

Jim,
Are you saying just make a container xml, like cnt_base.xml, with nothing in it?

-----Original Message-----
From: discuss discuss-bounces@lists.opencpi.org On Behalf Of James Kulp
Sent: Tuesday, June 19, 2018 9:21 AM
To: discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] HDL Assembly Makefile

Hi Peter,

It is true that nothing in container-* should be modified since it is all generated and cleaned.
When you are creating a non-default container (one that has interesting connections or non-default platform configuration), you put the container XML file in the assembly's directory and mention it in the Containers= variable in the Makefile.
In that container XML you specifiy what is "not default" about the container, any of:

1. Device connections of external ports of the assembly 2. Device presence (possibly parameterized) when not implied by device connections or platform configuration 3. The Platform Configuration to use (thus implying the presence of devices or cards).
   The container file you copied has a specifically indicated platform configuration.
   You probably just need to change the platform configuration indicated there to "base".

Jim

On 6/19/18 8:58 AM, Miller, Peter wrote:

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.

Peter,

If you are simply using the container you copied, on the same hardware,
but with your own assembly, you just need to make sure the "external"
attributes of the "connection" elements match the external ports of your
assembly.

If you want to use the base platform configuration rather than the
"config" mentioned in that file, you can just say "base" instead of
"cfg_1rx_1tx_fmcomms_2_3_lpc_lvds", but I'm not sure why you would do that.

Any parameters specified in that platform configuration must be repeated
in the container XML if you choose the base configuration.

Was there something about that platform configuration that you didn't
like or needed to change?

Jim

On 6/19/18 2:58 PM, Miller, Peter wrote:

Jim,
Turns out that I have another assembly that has this worker among others but will hook up like I want it for the zed.

Basically I have an application ACI that creates external Port/Buffer that connects to this worker (it's a wifi transmitter). In the xsim case I want an application that writes the output of the transmitter to a file. But I want the zed application to connect it to qdac. So I just made an assembly with this worker in it and nothing else, and the centos xsim file_write application finds this assembly and runs the app. Now for the zed, a different assembly is found that works and the app runs on the zed.

-----Original Message-----
From: James Kulp jek@parera.com
Sent: Tuesday, June 19, 2018 4:42 PM
To: Miller, Peter PeterM@signalscape.com; discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] HDL Assembly Makefile

Peter,

If you are simply using the container you copied, on the same hardware, but with your own assembly, you just need to make sure the "external"
attributes of the "connection" elements match the external ports of your assembly.

If you want to use the base platform configuration rather than the "config" mentioned in that file, you can just say "base" instead of "cfg_1rx_1tx_fmcomms_2_3_lpc_lvds", but I'm not sure why you would do that.

Any parameters specified in that platform configuration must be repeated in the container XML if you choose the base configuration.

Was there something about that platform configuration that you didn't like or needed to change?

Jim

On 6/19/18 2:58 PM, Miller, Peter wrote:

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

On 6/19/18 4:57 PM, Miller, Peter wrote:

Great.
You should be able to have one assembly, but different containers and
different applications.
The xsim container would have no connections, and the zed container
would have the connection to the dac.
Your ACI could simply have two different app xml strings, or with
ocpiriun, you would need two different app XML files.

That is exactly what I was thinking. But don't I need two xmls in the assembly - one that hooks the worker to the container connections (i.e. out_from_asm_tx_path_to_dac) and the other for the base container with no connections? How do you write the assembly xml to support, say three containers: zed, Matchstiq, and base? For base it's just:
<HdlAssembly>

<Instance worker="phy_tx_802dot11g" name="phy_tx_802dot11g" Externals="true"></Instance>

But for the zed container I have to add connections like:
<Connection Name="out_from_asm_tx_path_to_dac" External="producer">
<Port Instance="phy_tx_802dot11g" Name="out"/>
</Connection>

-----Original Message-----
From: discuss discuss-bounces@lists.opencpi.org On Behalf Of James Kulp
Sent: Tuesday, June 19, 2018 5:05 PM
To: discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] HDL Assembly Makefile

On 6/19/18 4:57 PM, Miller, Peter wrote:

Great.
You should be able to have one assembly, but different containers and different applications.
The xsim container would have no connections, and the zed container would have the connection to the dac.
Your ACI could simply have two different app xml strings, or with ocpiriun, you would need two different app XML files.

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.

That same HdlAssembly works in both cases.
When you say "externals='true'", you are saying that if the external
ports of the assembly are not connected, then connect them to software
(system bus).
So, when it looks at each container for the assembly (including the
default one), it sees which external ports are NOT connected in the
container XML, and connects those to software.
The zed container needs the extra connection to the dac since it is not
the default behavior.
The xsim container IS the default container, so it doesn't need to be
mentioned at all.

I.e. if your Makefile says:

Containers=cnt_1rx_1tx_thruasm_fmcomms_2_3_lpc_LVDS_zed

And then you build your assembly for both zed and xsim, it will build
three containers:

1. The default container for xsim, which will connect the assembly
   output to software.
2. The default container for zed, which will also connect the assembly
   output to software.
3. The specific container for zed which will connect the output to the dac.

On 6/19/18 5:21 PM, Miller, Peter wrote: