On Wed, Jan 15, 2020 at 9:26 PM Brian Padalino bpadalino@gmail.com wrote:

Working through this more, it seems like I need to add a <supports> tag
with the worker, device, and connections.  This would associated the
devices in very specific ways instead of generically or in an overloaded
way.

This would also seem to be the case for also enabling dual channel modes
for each of the AD9361 devices by connecting the other channel output to a
second ADC or DAC.

After adding all the <supports> tags, I am still getting a problem with the
ad9361_data_sub worker:

<supports> element for device "afe0_data_sub" on board "newplatform" does
not match any <supports> element on the "ad9361_data_sub" worker

I've determined it's the ad9361_adc_sub and ad9361_dac_sub tags which are
problematic.  Here is the beginning of the definition:

And the <supports> tags from the ad9361_data_sub.xml in OpenCPI looks like
this:

I can't find much information about this stuff, so I'll keep trying, but
someone who might know either how to get more debug out of why the tag
isn't matched would be great.

Again, any insight or help is appreciated.

Thanks,
Brian

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

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"

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...)
b) step through the code generator to find the "Multiple connections not
allowed" gets printed, and look into addition the proper functionality

This is my best guess at the moment...

---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Thu, Jan 16, 2020 at 10:10 AM
Subject: Re: [Discuss OpenCPI] Multiple AD9361 Devices Cause Multiple
Connections Error
To: discuss@lists.opencpi.org

On Wed, Jan 15, 2020 at 9:26 PM Brian Padalino bpadalino@gmail.com wrote:

Working through this more, it seems like I need to add a <supports> tag
with the worker, device, and connections.  This would associated the
devices in very specific ways instead of generically or in an overloaded
way.

This would also seem to be the case for also enabling dual channel modes
for each of the AD9361 devices by connecting the other channel output to a
second ADC or DAC.

After adding all the <supports> tags, I am still getting a problem with the
ad9361_data_sub worker:

<supports> element for device "afe0_data_sub" on board "newplatform" does
not match any <supports> element on the "ad9361_data_sub" worker

I've determined it's the ad9361_adc_sub and ad9361_dac_sub tags which are
problematic.  Here is the beginning of the definition:

And the <supports> tags from the ad9361_data_sub.xml in OpenCPI looks like
this:

I can't find much information about this stuff, so I'll keep trying, but
someone who might know either how to get more debug out of why the tag
isn't matched would be great.

Again, any insight or help is appreciated.

Thanks,
Brian

On Thu, Jan 16, 2020 at 12:08 PM Davis Hoover dhoover@geontech.com wrote:

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 thought by having the <supports> tag have the worker and the device in
it, the map would be pretty clear.

Definitely not really a good option for me.  Agreed on the yuck part.

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

I think I have recreated this issue locally. Let me do some poking around
in tools/ocpigen/* and get back to you.

---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Thu, Jan 16, 2020 at 1:49 PM
Subject: Re: [Discuss OpenCPI] Fwd: Multiple AD9361 Devices Cause Multiple
Connections Error
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org

On Thu, Jan 16, 2020 at 12:08 PM Davis Hoover dhoover@geontech.com wrote:

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 thought by having the <supports> tag have the worker and the device in
it, the map would be pretty clear.

Definitely not really a good option for me.  Agreed on the yuck part.

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

On Thu, Jan 16, 2020 at 4:54 PM Davis Hoover dhoover@geontech.com wrote:

Thank you.  I appreciate the help.

Let me know if you want me to try anything or give you any other
information regarding my setup.

Thanks,
Brian

Some debugging help: I often use make -n in these scenarios, which will
print to the screen the ocpigen commands being run - except in this case
where -n doesn't work, so I mod'd ocpigen to print out its arguments - then
stepped through the ocpigen command with gdb. The ocpigen command can also
be called w/ OCPI_LOG_LEVEL set to 8 or 10, which gives useful logging info.

There are lots of ordinals being handled here, in part to facilitate the
multi device<->subdevice worker scenario. One problem I have identified is
an incorrect ordinal inspection - I think this is the fix:

diff --git a/tools/ocpigen/src/hdl-config.cxx
b/tools/ocpigen/src/hdl-config.cxx
index bc0cfa5..d3412ff 100644
--- a/tools/ocpigen/src/hdl-config.cxx
+++ b/tools/ocpigen/src/hdl-config.cxx
@@ -327,7 +327,8 @@ emitSubdeviceConnections(std::string &assy,
DevInstances *baseInstances) {
// If there are no mapping entries, then we use the implicit
ordinal of the
// supports element among supports elements for that device type
if (s.m_supportsMap.empty()) {

•       if (si->m_ordinal != d.m_ordinal)
  

•       //if (si->m_ordinal != d.m_ordinal)
  

•       if (s.m_ordinal != d.m_ordinal)
          continue;
      } else {
        auto it =
  

This suspected fix causes other problems that I'm still looking into.

---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Thu, Jan 16, 2020 at 5:24 PM
Subject: Re: [Discuss OpenCPI] Fwd: Fwd: Multiple AD9361 Devices Cause
Multiple Connections Error
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org

On Thu, Jan 16, 2020 at 4:54 PM Davis Hoover dhoover@geontech.com wrote:

Thank you.  I appreciate the help.

Let me know if you want me to try anything or give you any other
information regarding my setup.

Thanks,
Brian

Brian/Davis,

I am assuming that both ad9361s share the same SPI bus?

If you have two ad9361s sharing a single SPI, then you need a different
SPI subdevice worker that supports both ad9361s.  The existing one only
works when the SPI is not shared.

Thus having two ad9361_spi devices would be wrong.  Normally a SPI
subdevice worker is specific to a platform and supports all the devices
that share the same SPI bus (or other signals).

The purpose of the ocpigen code as it is, is when one subdevice is
supporting multiple devices of the same type, where there are multiple
"supports" relationships between that one SPI subdevice and the devices
that share it.

So the solution here depends on the actual SPI-sharing in your hardware
platform.

Unfortunately, the current system does not support "scalable
subdevices", where we can parameterize it to have a type of "supports"
that is an "array" of supported devices of the same type.

Jim

On 1/17/20 4:57 PM, Davis Hoover wrote:

Hey James,

On Sun, Jan 19, 2020 at 5:56 PM James Kulp jek@parera.com wrote:

Actually, in my application, I have two separate SPI buses.  But, those SPI
buses have more than just the AD9361 hanging off of them, so I will somehow
have to share the clock, and data lines while having a different chip
select for a different device.  Do you have any suggestions on supporting
that?

Thanks,
Brian