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