On Thu, Jan 16, 2020 at 12:08 PM Davis Hoover <dhoover_at_geontech.com> wrote:
> Hey Brian,
>
> The supports relationship of the existing AD9361 device/subdevice worker
> should not need to be modified. There is a good diagram of these
> relationships here:
>
> https://github.com/opencpi/training/blob/master/PDFs/presentations/Extra_Device_Support_Development.pdf
>
> The multi-channel instantiation does not suffer from the problem in
> question, and is exemplified by both the aforementioned pdf and the
> following assembly container:
>
> https://github.com/opencpi/opencpi/blob/release_1.5/projects/assets/hdl/assemblies/empty/cnt_2rx_2tx_bypassasm_fmcomms_2_3_lpc_LVDS_zed.xml
Thanks for the PDF link. That shows a much better relationship that I was
picturing in my head.
The assembly container, though, only shows a single AD9361 device, but both
channels being utilized. My situation is that I have a board which can be
populated such that I have a spot for two AD9361 devices, and one can be
populated in either position. So the ad9361_spi, ad9361_config,
ad9361_data_sub all need to be doubled up (due to physical platform
mappings), but the ad9361_adc_sub, ad9361_dac_sub, ad9361_adc, and
ad9361_dac can be free-form associated.
>
>
> I *think* the problem is: you can have a subdevice worker which supports
> multiple instances of a single device worker:
> worker=foo.hdl, pfconfig/container instname=foo_0
> worker=foo.hdl, pfconfig/container instname=foo_1
> worker=foo_sub.hdl(supports foo.hdl), pfconfig/container instname=foo_sub
>
> ...but you *cannot* have multiple *subdevice workers*, each of which
> support the same device worker
> worker=foo.hdl, pfconfig/container instname=foo_0
> worker=foo.hdl, pfconfig/container instname=foo_1
> worker=foo_sub.hdl(supports foo.hdl), pfconfig/container instname=foo_sub_0
> worker=foo.hdl, pfconfig/container instname=foo_2
> worker=foo.hdl, pfconfig/container instname=foo_3
> worker=foo_sub.hdl(supports foo.hdl), pfconfig/container instname=foo_sub_1
> ... in this scenario, both foo_sub_0 and foo_sub_1 are trying to make a
> connection to foo_0 and foo_1, due to missing functionality in the code
> generator, which is what the code generator is complaining about with
> "multiple connections not allowed"
>
I thought by having the <supports> tag have the worker and the device in
it, the map would be pretty clear.
>
> Off the top of my head, the two possible workarounds I envision are:
> a) copy all device workers with a new name, e.g. ad9361_data_sub_copy.hdl,
> with the subdevice connections of the copies being modified to refer to all
> _copy versions (yuck...)
>
Definitely not really a good option for me. Agreed on the yuck part.
> b) step through the code generator to find the "Multiple connections not
> allowed" gets printed, and look into addition the proper functionality
>
I've been tracking down the reason why the <supports> element can't be
found even though there is a match obviously there.
I'm looking here:
https://github.com/opencpi/opencpi/blob/v1.5.1/tools/ocpigen/src/hdl-device.cxx#L229
Specifically on line 242 where the worker name is compared against the
supports, but it's also checking ordinality. If a match is found, a pair
of worker name and ordinality is set to the device string in m_supportsMap.
The part I find strange is that I am specifically calling out the device I
want in my <supports> tag.
Should this mapping really exist? I am confused by the ordinality aspect
to this mapping.
Can you shed any light on this? Am I looking at the right spot in the code
to try to support what I want?
Thanks,
Brian
Received on Thu Jan 16 2020 - 18:49:39 CST