I am trying to get the FSK DRC example working on my platform but there is
so much abstraction I can't figure out how to set the output to be from
TX1A on the AD9361.

I need to set the tx_rf_port_output property to 0 instead of being 1.  I
need the config register general_input_select to be 3 instead of 76.  I
have a custom DRC controller, but I have no idea how to set what I need to
set in there.  Any attempts seem to fail miserably.

I am using ocpirun to run my XML file.  Any help or guidance would be
appreciated.

Thanks,
Brian

Thanks for the detailed feedback.

There's a lot to digest here, and I will be providing several responses later this week.

Cheers,

Jim

On 3/12/21 5:50 PM, Brian Padalino wrote:

On Thu, Mar 11, 2021 at 10:52 PM Davis Hoover <dhoover@geontech.com> wrote:

All but 3 lines of the 39 results refer to older or lower-level RCC proxies that overlap in functionality with the DRC (which should probably be consolidated...).

It's great that you know that. How is that useful to someone who is not intimately familiar with OpenCPI?

Here is a DRC briefing - slide 18 might provide a little more context (and exemplify the degree of abstraction!)
https://opencpi.gitlab.io/releases/latest/docs/briefings/Briefing_14_Digital_Radio_Controller.pdf

It isn't very helpful because it doesn't show the interaction of how callback structures/objects work with each other. Moreover, the structure is called DoSlave which isn't very descriptive. As I said above, it's great that someone knows what it does, but for someone coming into it, even with the briefing, it isn't well documented at all.

Abstraction does contribute to complexity here, but it also enables the interoperability afforded by DRC. DRC solves two essential problems: 1) abstraction and portability of radio command/control, and 2) intelligent erroring and prevention of radio misconfiguration. No. 2 is a hard problem, especially in the AD9361 case (whack-a-mole issues where changing one setting changes another setting) - you're solving that hard problem now so application developers down the road don't have to know a thing about AD9361. I'm not aware of any other framework that solves problem 2.

For (1) I don't think OpenCPI adds anything that JTRS or any other framework didn't already try to solve beforehand. It may be less cumbersome, but I don't think it's time to declare Mission Accomplished.

As for (2), I am surprised you're trying to take some type of credit for wrapping the ADI no-os ad9361 library. Credit should go to ADI for creating not only a spectacularly well documented linux kernel driver, but also porting it over for implementations that want to run bare metal. Moreover, when multiple ad9361's are instantiated, OpenCPI doesn't fail gracefully at all. It confuses the two devices even though they have unique names associated with their instantiations. As of v2.1.0-rc.2, I've gotten segfaults in applications due to this confusion and misconfiguration, so I don't have the confidence in (2) that you seem to have.

My problem with your approach to (2) is that the ADI library is completely hidden away from the developer. Also, the ad9361 OpenCPI HDL implementation doesn't support the dynamic calibration for TX/RX data that is included with the ADI HDL/drivers. Instead, the LVDS delays are built into the FPGA image which doesn't make any sense to me.

There could certainly be improvements. As for documentation, much effort was initially put into Doxygen comments (e.g. https://gitlab.com/opencpi/opencpi/-/blob/develop/runtime/drc/ad9361/include/RadioCtrlrNoOSTuneResamp.hh). Please feel free to offer specific recommendations or alternatives - documentation or otherwise.

I don't see what doxygen comments you're looking at in the link. There's nothing really around getRfOutput() or getRfInput(). Further down in the file, why are there functions talking about CIC's and complex mixers for the Radio Controller? What resampling is going on here? If I were just given that header file, I am not sure where to start or what it means. Even the filename just sounds like a lot of terms crammed together.

Examples of documentation I like:

https://github.com/Nuand/bladeRF/blob/master/host/libraries/libbladeRF/include/libbladeRF.h which creates ...

https://nuand.com/bladeRF-doc/libbladeRF/v2.2.1/ and has full examples like ...

https://nuand.com/bladeRF-doc/libbladeRF/v2.2.1/sync_rx_meta.html with appropriate error handling included in the examples

https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9361 which has devicetree documentation ....

https://github.com/analogdevicesinc/linux/blob/master/Documentation/devicetree/bindings/iio/adc/adi,ad9361.txt which is verbosely documented and has an example at the bottom

Since you asked for recommendations, I can only speak to my experience with taking an existing radio based on a Zynq architecture that was already working and OpenCPI support was requested to be added. Here's my list:

• OpenCPI Environment setup is long, cumbersome, and unnecessary

When setting up OpenCPI, I need to build assets for configurations that I do not need for my FPGA implementation. This is very long, and cumbersome. The time it takes to set up OpenCPI should be no longer than it takes to compile the runtime, and source the cdk environment.

When synthesizing designs, or compiling code, all source required should be generated on the fly and referenced. Get rid of having to build EDIF netlists for every small component in every possible configuration. The configurations are just generics anyway - use them in the code. This makes doing ILA debugging significantly easier as well.

My ideal scenario is to:

• Clone the OpenCPI repository and build the runtime (this step works fine as it is)

• Clone an osp project and add it to OpenCPI (this step works fine as it is)

• Navigate to an assembly in that osp, and run ocpidev build to generate all required code across all OpenCPI projects as needed, create a project from that source, and build the assembly

This allows me to examine the full source of the system in a single project and minimizes my time building unnecessary netlists that I won't ever need. Moreover, it allows me to modify core OpenCPI components without having to rebuild multiple configurations when I only need one. Sure, I could comment out the build of the other unnecessary configurations, but why should that be necessary? I have no idea why this can't be done right now other than lack of development effort.

My last complaint about the OpenCPI build environment is that it is so slow that re-running ocpidev build in the assets project where all HDL components are 100% completely built and there is no new code generation or rebuilding still takes many minutes. Minutes to check that files exist and do nothing. Why does it take so long? I have no idea what is being done behind the scenes, but this seems terrible to me.

• OpenCPI wants to be the ecosystem, and not a component in an existing ecosystem

Instead of being a component of my entire system, OpenCPI wants to run everything. This is backwards. The DRC FSK application is a great example since it could have been amazingly simple, but instead is absurdly cumbersome.

The fsk_modem assembly only cares about getting a complex data input in some format, doing some small signal processing, and then outputting a decimated/filtered complex data stream output. If the assembly were built as an AXI component I can instantiate in my system, I could have had a massive amount of code reuse. The ad9361 interfaces were all vetted and working. I just needed the actual guts of the HDL (MFSK mapper, filtering, etc) and the RCC to be able to talk to that HDL component.

Instead, OpenCPI wants to run everything. So I lose the fully proven ad9361 interface with dynamic timing adjustments, and the control over custom RF boards, and instead I need to bring all of that into OpenCPI which is error prone and cumbersome to say the least. In fact, if I want to have a few different Xilinx soft IP AXI slaves (maybe some GPIO or UART slaves) hanging off the same bus - that's just impossible.

I understand OpenCPI has a desire to provide a full solution for development kits and therefore needs to have the full platform support, but at least make that part optional. Adding OpenCPI to a Zynq system should be nothing more than plopping down an AXI connected component.

• OpenCPI doesn't know what value it wants to add

Your claims above that OpenCPI provides portable command/control and intelligent error handling sounds like great value. Frameworks should strive to provide that without getting in the way. Unfortunately, OpenCPI also requires me to build and install custom kernel drivers, and needs to handle loading FPGA images. OpenCPI handling these functions does not add value.

Here's a userspace mappable DMA buffer:

https://github.com/ikwzm/udmabuf

Couple that with uio in the standard kernel, and device tree overlay support in the standard kernel, and you have a much better system than you do today regarding FPGA images. In fact, OpenCPI would be much easier to adopt if a conglomeration of OpenCPI workers/components just had an AXI interface on it and spit out a device tree entry/overlay to add to the system. Then OpenCPI can focus on being an addition to a system rather than trying to take it over.

I hope you take this list seriously from someone who has worked for the past year porting OpenCPI (v1.5.1, v1.6.0, v1.7.0, v2.0.0, v2.0.1, and v2.1.0) to the same platforms - always having bugs, problems, and needing patches to get things working. In my experience, "easy to use" and "portable" are not words I would use to describe OpenCPI.

Feel free to address my comments and suggestions on or off list.

Brian

<pre class="moz-quote-pre" wrap="">_______________________________________________
discuss mailing list -- <a class="moz-txt-link-abbreviated" href="mailto:discuss@lists.opencpi.org">discuss@lists.opencpi.org</a>
To unsubscribe send an email to <a class="moz-txt-link-abbreviated" href="mailto:discuss-leave@lists.opencpi.org">discuss-leave@lists.opencpi.org</a>

Brian,

We understand the frustration for sure but it's better to have a conversation of "here's what didn't work for me", "here are some potential things to make it better", "adding xyz to the documentation would have made it better".

Better for the conversation to leave out the negative comments and give constructive criticism.

From: Brian Padalino bpadalino@gmail.com
Sent: Friday, March 12, 2021 5:50 PM
To: dhoover@geontech.com dhoover@geontech.com
Cc: discuss@lists.opencpi.org discuss@lists.opencpi.org
Subject: [Discuss OpenCPI] Re: DRC and AD9361 Config

On Thu, Mar 11, 2021 at 10:52 PM Davis Hoover <dhoover@geontech.commailto:dhoover@geontech.com> wrote:
All but 3 lines of the 39 results refer to older or lower-level RCC proxies that overlap in functionality with the DRC (which should probably be consolidated...).

It's great that you know that.  How is that useful to someone who is not intimately familiar with OpenCPI?

Here is a DRC briefing - slide 18 might provide a little more context (and exemplify the degree of abstraction!)
https://opencpi.gitlab.io/releases/latest/docs/briefings/Briefing_14_Digital_Radio_Controller.pdf

It isn't very helpful because it doesn't show the interaction of how callback structures/objects work with each other.  Moreover, the structure is called DoSlave which isn't very descriptive.  As I said above, it's great that someone knows what it does, but for someone coming into it, even with the briefing, it isn't well documented at all.

Abstraction does contribute to complexity here, but it also enables the interoperability afforded by DRC. DRC solves two essential problems: 1) abstraction and portability of radio command/control, and 2) intelligent erroring and prevention of radio misconfiguration. No. 2 is a hard problem, especially in the AD9361 case (whack-a-mole issues where changing one setting changes another setting) - you're solving that hard problem now so application developers down the road don't have to know a thing about AD9361. I'm not aware of any other framework that solves problem 2.

For (1) I don't think OpenCPI adds anything that JTRS or any other framework didn't already try to solve beforehand.  It may be less cumbersome, but I don't think it's time to declare Mission Accomplished.

As for (2), I am surprised you're trying to take some type of credit for wrapping the ADI no-os ad9361 library.  Credit should go to ADI for creating not only a spectacularly well documented linux kernel driver, but also porting it over for implementations that want to run bare metal.  Moreover, when multiple ad9361's are instantiated, OpenCPI doesn't fail gracefully at all.  It confuses the two devices even though they have unique names associated with their instantiations.  As of v2.1.0-rc.2, I've gotten segfaults in applications due to this confusion and misconfiguration, so I don't have the confidence in (2) that you seem to have.

My problem with your approach to (2) is that the ADI library is completely hidden away from the developer.  Also, the ad9361 OpenCPI HDL implementation doesn't support the dynamic calibration for TX/RX data that is included with the ADI HDL/drivers.  Instead, the LVDS delays are built into the FPGA image which doesn't make any sense to me.

There could certainly be improvements. As for documentation, much effort was initially put into Doxygen comments (e.g. https://gitlab.com/opencpi/opencpi/-/blob/develop/runtime/drc/ad9361/include/RadioCtrlrNoOSTuneResamp.hh). Please feel free to offer specific recommendations or alternatives - documentation or otherwise.

I don't see what doxygen comments you're looking at in the link.  There's nothing really around getRfOutput() or getRfInput().  Further down in the file, why are there functions talking about CIC's and complex mixers for the Radio Controller?  What resampling is going on here?  If I were just given that header file, I am not sure where to start or what it means.  Even the filename just sounds like a lot of terms crammed together.

Examples of documentation I like:

https://github.com/Nuand/bladeRF/blob/master/host/libraries/libbladeRF/include/libbladeRF.h which creates ...
https://nuand.com/bladeRF-doc/libbladeRF/v2.2.1/ and has full examples like ...
https://nuand.com/bladeRF-doc/libbladeRF/v2.2.1/sync_rx_meta.html with appropriate error handling included in the examples

https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9361 which has devicetree documentation ....
https://github.com/analogdevicesinc/linux/blob/master/Documentation/devicetree/bindings/iio/adc/adi,ad9361.txt which is verbosely documented and has an example at the bottom

Since you asked for recommendations, I can only speak to my experience with taking an existing radio based on a Zynq architecture that was already working and OpenCPI support was requested to be added.  Here's my list:

• OpenCPI Environment setup is long, cumbersome, and unnecessary
  When setting up OpenCPI, I need to build assets for configurations that I do not need for my FPGA implementation.  This is very long, and cumbersome.  The time it takes to set up OpenCPI should be no longer than it takes to compile the runtime, and source the cdk environment.

When synthesizing designs, or compiling code, all source required should be generated on the fly and referenced.  Get rid of having to build EDIF netlists for every small component in every possible configuration.  The configurations are just generics anyway - use them in the code.  This makes doing ILA debugging significantly easier as well.

My ideal scenario is to:

• Clone the OpenCPI repository and build the runtime (this step works fine as it is)
• Clone an osp project and add it to OpenCPI (this step works fine as it is)
• Navigate to an assembly in that osp, and run ocpidev build to generate all required code across all OpenCPI projects as needed, create a project from that source, and build the assembly

This allows me to examine the full source of the system in a single project and minimizes my time building unnecessary netlists that I won't ever need.  Moreover, it allows me to modify core OpenCPI components without having to rebuild multiple configurations when I only need one.  Sure, I could comment out the build of the other unnecessary configurations, but why should that be necessary?  I have no idea why this can't be done right now other than lack of development effort.

My last complaint about the OpenCPI build environment is that it is so slow that re-running ocpidev build in the assets project where all HDL components are 100% completely built and there is no new code generation or rebuilding still takes many minutes.  Minutes to check that files exist and do nothing.  Why does it take so long?  I have no idea what is being done behind the scenes, but this seems terrible to me.

• OpenCPI wants to be the ecosystem, and not a component in an existing ecosystem
  Instead of being a component of my entire system, OpenCPI wants to run everything.  This is backwards.  The DRC FSK application is a great example since it could have been amazingly simple, but instead is absurdly cumbersome.

The fsk_modem assembly only cares about getting a complex data input in some format, doing some small signal processing, and then outputting a decimated/filtered complex data stream output.  If the assembly were built as an AXI component I can instantiate in my system, I could have had a massive amount of code reuse.  The ad9361 interfaces were all vetted and working.  I just needed the actual guts of the HDL (MFSK mapper, filtering, etc) and the RCC to be able to talk to that HDL component.

Instead, OpenCPI wants to run everything.  So I lose the fully proven ad9361 interface with dynamic timing adjustments, and the control over custom RF boards, and instead I need to bring all of that into OpenCPI which is error prone and cumbersome to say the least.  In fact, if I want to have a few different Xilinx soft IP AXI slaves (maybe some GPIO or UART slaves) hanging off the same bus - that's just impossible.

I understand OpenCPI has a desire to provide a full solution for development kits and therefore needs to have the full platform support, but at least make that part optional.  Adding OpenCPI to a Zynq system should be nothing more than plopping down an AXI connected component.

• OpenCPI doesn't know what value it wants to add
  Your claims above that OpenCPI provides portable command/control and intelligent error handling sounds like great value.  Frameworks should strive to provide that without getting in the way.  Unfortunately, OpenCPI also requires me to build and install custom kernel drivers, and needs to handle loading FPGA images.  OpenCPI handling these functions does not add value.

Here's a userspace mappable DMA buffer:

https://github.com/ikwzm/udmabuf

Couple that with uio in the standard kernel, and device tree overlay support in the standard kernel, and you have a much better system than you do today regarding FPGA images.  In fact, OpenCPI would be much easier to adopt if a conglomeration of OpenCPI workers/components just had an AXI interface on it and spit out a device tree entry/overlay to add to the system.  Then OpenCPI can focus on being an addition to a system rather than trying to take it over.

I hope you take this list seriously from someone who has worked for the past year porting OpenCPI (v1.5.1, v1.6.0, v1.7.0, v2.0.0, v2.0.1, and v2.1.0) to the same platforms - always having bugs, problems, and needing patches to get things working.  In my experience, "easy to use" and "portable" are not words I would use to describe OpenCPI.

Feel free to address my comments and suggestions on or off list.

Brian