Open Research Institute Presentations, 24 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GRCon20 - Introducing OpenCPI as an Infrastructure for GNU Radio and GNU Radio Companion

Description

Presented by Jim Kulp at GNU Radio Conference 2020 https://gnuradio.org/grcon20

Software-Defined Radio (SDR) applications developed using GNU Radio are typically based on embedded heterogeneous systems with a variety of processors, FPGAs and transceivers. But the ability of a GNU Radio based SDR application to target a variety of different heterogeneous system configurations is limited and requires significant configuration-specific development work. The existing method for GNU Radio to support various hardware configurations is through specific software and toolsets that support specific vendors’ hardware.

An alternative, and better solution is for GNU Radio to have an open infrastructure that supports heterogeneous processing and a breadth of hardware and toolchains in order to avoid the limitations of vendor-based hardware and tool-chain solutions. The breadth of hardware that it supports must include multiple processor architectures (e.g. general, multi-core, manycore processors, GPUs), different FPGA and FPGA toolchains, and devices such as transceivers. The infrastructure must be well suited to maximize data transfer rates within heterogeneous systems and must maintain the GNU Radio component-based workflow, including the GRC application development environment.

OpenCPI is an open-source software framework for developing and executing component-based applications on heterogeneous embedded systems. The latest OpenCPI integration with GNU Radio, now provides the needed open infrastructure for supporting heterogeneous processing. This talk presents the current state of the GNU Radio integration with the OpenCPI infrastructure, some of which was previewed at GRCon17. It will discuss how the integration of OpenCPI with GNU Radio will allow GR blocks to have alternative implementations, such as C++ or VHDL, ready to run on CPUs or with different FPGA vendors and configurations. The OpenCPI framework selects the appropriate performance-oriented implementation of every block to be used depending on the available hardware and can execute an application across multiple, different SDRs.

This talk will address how OpenCPI provides hardware vendor independence and tool-independent infrastructure and development flow. It will present how the integration of OpenCPI with GNU Radio will enable applications to both exploit all the hardware as well as be easily ported to very different hardware or facilitate technology insertion.

The speaker for this talk will be James Kulp, the founder and architect for the OpenCPI project.

James Kulp has more than 30 years of experience in the real-time computing industry. Currently he is a Consulting Software Architect involved with several DoD related embedded architecture efforts. He previously was the architect for scalable heterogeneous multi-computer operating systems at Mercury Computer Systems, Inc.

Before joining Mercury, Mr. Kulp served as a product architecture consultant and board member of Surety Technologies, Inc. He was a systems software consultant for operating systems analysis and remote management at Digital Equipment Corporation; founder and vice president of Superscript, Inc., which made tablet-based systems; vice president of intelligent data acquisition subsystems technology for Event Technologies, Inc.; and founder and program manager at Symbolics, Inc. Mr. Kulp has also served as the computer services department head at the International Institute of Applied Systems Analysis, and was founder and vice president of technology for Graphic Management Systems, Inc.

Mr. Kulp attended the Massachusetts Institute of Technology where he studied computer science, management, and architecture.

A

James culp has more than 30 years of experience in the real-time computing industry. Currently he is a consulting software architect involved with several dod related embedded architecture efforts. He previously was the architect for scalable heterogeneous multi-computer operating systems at mercury computer systems before joining mercury. Mr kulp served as a product architecture consultant and board member of surety technologies.

A

He was a systems, software consultant for operating systems, analysis and remote management at digital equipment, corporation founder and vice president of superscript, which made tablet-based systems vice president of intelligent data, acquisition, subsystems, technology for event, technologies and founder and program manager at symbolics.

A

Mr kulp has also served as the computer services department head at the international institute of applied systems, analysis and was founder and vice president of technology for graphic management systems.

A

Mr culp attended the massachusetts institute of technology where he studied computer science, management and architecture.

B

Good morning, at least in the time zone chosen for the conference schedule it's morning, I'm jim kulp, architect of opencpi and I'm going to be talking about opencpi and how it can serve as an infrastructure for gnu, radio and goo radio companion companion today, we'll talk about how opencpi can address the diversity of hardware and firmware in sdrs and how that can help with gnu radio.

B

First we'll talk about hardware, diversity in sdrs and then how opencpi works with new radio and canoe radio companion on diverse radios. Next, we will describe the kinds of development processes that are supported in opencpi.

B

This includes how it supports developing components in this environment, how you develop support for new hardware and, of course, using the radio companion, how you construct applications.

B

Finally, we'll wrap up with why and when we think cpi should be used and a roadmap for where things are going next. This is the overall picture of how things fit together and we will go into more detail shortly under gnu radio companion. We add open cpi blocks for cpus and fpgas to the existing radio blocks and run them all together.

B

On a combined runtime environment that includes hardware drivers on both cpus and fpgas, let's start with the basic idea that sdrs can be built in many different ways with different parts: chips, processors, but they all have a common structure, which is that there is some configurable hardware near the antenna, there's some programmable processing resources that do the sdr processing, sometimes called modem, processing or waveform processing or just signal processing.

B

And then finally, there is a user interface to what this radio is doing, or some services software that is, making the radio a service integrated into some larger environment. So we have the interface between the hardware and the sdr processing and the interface between the sdr processing and the user interface or services integration. Software nearly all sdrs fit this model, even when the sdr is in fact a laptop pc with a usb dongle plugged into it.

B

So let's investigate this idea that sdrs are built in many different ways, with diversity of design across vendors and within vendor product lines.

B

Our first example is what is perhaps the smallest and cheapest sdr the rtl str usb dongle radio, which consists of some configurable tuner receiver hardware that plugs into a pc. It has no fpgas and all the sdr processing, as well as user interface. Software runs on the pc.

B

Our next example is one of the many radios available from epic solutions, and in this case it uses the popular adi transceiver front, end circuit. It has a small fpga and it has a usb or pci express connection to a host pc.

B

So in this case the front end is more powerful and configurable than the previous one.

B

Some time sensitive processing can happen in the small fpga and the rest of the processing has to happen in the pc that it is plugged into.

B

Our next example is the small pluto radio from adi called their advanced learning module and it has the same front end as the previous radio. It uses a xylinx zinc chip which has both an fpga section and an armcore cpu section connected on chip using an axi interface, and it also has a usb or ethernet connection to a host pc. The fpga is quite small, the smallest of that product line, but it can do significant processing.

B

The arm cpu in the same chip is available to assist in processing in close proximity to and thus reduced latency with the fpga processing and higher level processing can, as usual, be offloaded to the attached host pc.

B

Our final example is the edis x310 radio, which is a powerful member of their broad product line of radios. The front end is not just a chip but a powerful combination of rf transceivers and higher speed, adcs and dax for higher speed sampling.

B

There's a large fpga and this radio is attached to the host pc via pci, express or 10 gigabit ethernet.

B

In this case, there is a lot of capacity for processing in the large fpga and there is a high performance, high bandwidth connection to the host pc or whatever processor it is connected to, and so a lot of process that can happen in the fpga and perhaps less being required in the host pc.

B

As you can see, there are many different ways: radios are built with different types of processing happening in different places. The challenge is how, and where do I put my sdr processing or in new radio terms, the blocks in my flow graph? There are many ways it can happen on different processors of different types, with different interfaces for the data flowing between blocks on different types of processors.

B

This is hardware diversity in sdrs.

B

We just looked at hardware diversity in sdrs and how they're put together and how different they can be, and now we'll look at the other side of it, which is how they are programmed.

B

Happily, the new radio and its runtime and the gnu radio companion solves this problem for what runs on the primary cpu. You have one way of writing blocks a common runtime, a common user interface, regardless of how the radios are designed, which is a great thing.

B

So for our first radio, gnu radio needs to have source blocks that talk to the vendors api and thus the vendors library, which of course knows how to talk to the hardware in the radio.

B

That's a pretty simple situation, because there is just software and just software on the pc, but it is a vendor api talking to vendor hardware, that is mostly two easily available chips, one of which has a normal data sheet and the other one has a reverse engineered feature set.

B

Our second radio from epic is programmed with their api and their library, and since they have an fpga in this radio, they also have a reference design for the fpga and have what's called a platform development kit to enable customers to customize the processing on the fpga. They also have some hardware access capabilities, some from the fpga and some from the processor, if it isn't obvious so far, the cross-hatched, blue and green boxes in the diagrams are a mix of, or choice of, fpga and cpu processing.

B

Our third example, radio, the adi pluto, also has an api called lib, iio and adi includes linux, dma and device drivers and on the fpga, that's in the pluto. There are reference projects and a library of ip blocks and the hardware access in that radio is nearly all from the fpga. So the fpga talks to the devices and the host cpu talks to the embedded arm, cpu, which talks to the fpga.

B

Our final example, radio is again the nsx 310, with the big fpga and edis has their api called uhd, which provides source and sync blocks for gnu radio. Using that uhd api addis also provides a serious fpga toolkit called rfnoc, which constructs processing configurations for the fpga.

B

The radio front-end hardware is accessed entirely from the fpga in this radio.

B

So the summary here really is that we have four vendors, four apis and three fpga toolkits.

B

So our conclusion is that there is a lot of diversity in sdrs, different types of processing, different mixes of processing, different ways of connecting processors, different hardware, vendors with different apis, sdks and toolkits.

B

I didn't mention it before, but the fpga chip vendors themselves have tool kits that are very different and even the various fpga simulation tools are different.

B

So opencpi brings consistency and commonality to the parts of sdrs that gnu radio has not focused on where sdr processing is mixed between processors of different types and the programming models and tools have been vendor-specific.

B

Much like linux provides a common environment for most embedded processing with device drivers for different hardware elements. Opencpi provides an analogous model for the fpga environment, also with the equivalent of device drivers, while there are only tens of developers, expanding and evolving opencpi. Linux has thousands, but we believe we are achieving a similar objective of a common model for all of sdr processing.

B

So I'd like to summarize here what opencpi is and describes, some of its important attributes is open source. It is a component based environment like gnu radio. It is a development and runtime framework. There are tools for the development process as well as runtime libraries and drivers to deploy and run applications.

B

Opencpi is designed for embedded systems on diverse hardware that was its first and primary purpose when it was designed, and that remains the priority during its evolution when we say diverse hardware, we're talking about different types of processors, including fpgas, with components executing across all the processors and types in the system.

B

This requires device driver models where sometimes device code is written directly to hardware, but sometimes it is simply using existing open vendor supplied code for their hardware, which is then integrated and wrapped into opencpi sdrs, usually with gnu radio are really the most important class of embedded systems for opencpi.

B

So the primary purpose here is to enable applications to target diverse hardware and that diversity can be up front, meaning, I know the five systems. I want my application to use in different situations, or I want to know that my application will be easily moved to new hardware platforms in the future. If I use this framework even for platforms, I am not aware of yet yet how exactly does opencpi relate to gnu radio and the gnu radio companion?

B

First of all, they are both component-based environments, and so the concept of a gnu radio block is similar to the concept of an open cpi component. We'll get into more detail on that in a minute.

B

A good new radio flow graph, which is an assembly of blocks that will together perform some function, is the same concept as an opencpi application.

B

Opencpi uses the gnu radio companion as an application builder, so that it's it is the same user interface used by gnu radio users to build applications and flow graphs.

B

We have modified the guinea radio companion so that it can build and run open cpi applications across cpus and fpgas. In addition to its current function, which is building and running new radio flow graphs, open cpi is currently being modified to execute most new radio blocks. As part of the overall heterogeneous application, in other words the runtimes, are being connected since opencpi is an infrastructure, it can thus act as a vendor-independent heterogeneous infrastructure for gnu radio applications and enable them to more easily migrate to diverse hardware.

B

Now we'll describe opencpi in more detail by describing the three distinct development processes it supports. The first one component development is what creates the libraries of components for applications to use.

B

The second platform development creates the support packages for new hardware and the third application development uses the results of the first two to create and deploy sdr applications. So.

A

B

We'll discuss component development in more detail component development and open cpi creates the building blocks for applications just like in gnu radio. You create blocks, at least in part, using the gr, mod tool etc, but in opencpi there is a clear separation between the component specification, meaning the contract or the functional definition and the implementation of that component.

B

The component has an xml based specification, a unit test suite and a datasheet describing what that component does. And then we have separate from the component spec implementations, which are source codes that implement that specification. We call these workers, so a component is really a collection of these source codes and a common spec that they all implement, including a common unit test, so that when we test them, we know they all implement the same functions.

B

It is common to have workers written in different languages for different processor types, such as c plus and vhdl.

B

The deliverable from the component development process is a library of related components, each of which has specs unit tests, documentation and some workers.

B

This creates a deliverable that is ready for application development on diverse hardware, since the components have different workers that can run on diverse hardware.

B

This all means that the application development process can experiment using different workers on different processors, simply by directing the execution of the component to be on a different processor, which will automatically use the appropriate worker.

B

Note that in the example component, a in the diagram below we have a c plus plus worker, a vhdl worker and a third worker that is also vhdl but optimized for xylinx fpgas, to elaborate a little more on the concept of components and workers.

B

This diagram shows a component encrypt and there are two apis or authoring models or ways to write workers represented by the hdl and the rcc.

B

Each of those authoring models supports one or more languages to write the worker for that api or authoring model, and we have examples of vhdl, c and c plus the vhdl language might result in two different source codes, one that was big and fast and used a lot of resources but ran fast and the other one was very skimpy on resources.

B

But was, and we might have a c version that is designed for small processors that might not even have a good c plus plus compiler and then a normal c plus plus worker each of those could be compiled for appropriate targets and thus delivering a library could deliver all the workers and all of their compiled results for a wide variety of targets.

B

So next we'll move on to the second development process in opencpi platform development platform development is the process for creating a deliverable that enables opencpi on new hardware, and usually it is a package that contains whatever is necessary to support all the new hardware. On a given system for embedded processors running software. The package might contain, or refer to cross tools, kernel headers boot files for what we call the software platform in the system for fpgas the package might contain or refer to tools, drivers, loading mechanisms, including descriptions of slots for daughter cards.

B

The structured deliverable is what we call an osp, an open cpi system, support project which is analogous to the less well-defined idea of a bsp or board support package.

B

Since the support for embedded processors embedded fpgas and devices in a system are all modular, that means an osp might not contain some of them if they are already existent elsewhere.

B

In the example deliverable here, there is a device driver for an adc analog to digital converter, which means that driver was not already supported in opencpi for a previous system. The fpga, in this case is the fpga part of the zinc ultra scale system on chip from xilinx, and the software platform is based on the xilinx cross tools and kernel from their 2019.2 release for 64-bit arm processors.

B

This software platform would be the same as for any other xilinx-based 64-bit arm cpu. So even that support might not need to be in this osp. This table presents supported devices and platforms.

B

The first row is is what is supported in 2.0. The second is what is under development, either by the opencpi team or known to be under development by third parties, and the third one is uh where we know there's intention to do these and to work on them, but they're, not under development. Yet the important point here is that platforms or or a system or an osp, uh consists of all the supported pieces and so uh frequently an osp will have pieces that are already supported for for other systems.

B

And that's why we have columns like transceivers and interfaces and fpgas and tools, because a typical osp picks from the existing support, supported elements and then just fills in the gaps.

B

So finally, we'll discuss application development, which is the third development process in open cpi.

B

Application development is, of course, built on the results from the previous two development processes.

B

It assembles components into applications using the gnu radio companion to assemble blocks into those applications, just like it does, for gnu radio blocks into flow graphs and given the available component, libraries applications are ready to run on diverse hardware, because those libraries contain diverse implementations of components.

B

An application is represented by an xml file or, in some cases a custom c plus plus main program which uses what we call the application control interface to launch, configure and control the xml application.

B

There's also a prototype of the application control interface in python.

B

The deliverable for the application is the xml specification or in some cases, the executable using the aci and then packaged with that would be the workers that have been built for the desired targeted software platforms, as well as the fpga configurations for the potential targeted fpga platforms component. Libraries used by application developers can come from a number of different places, the first being the built-in projects in the opencpi repository which contain a basic set of components.

B

And then there are other opencpi projects that are in other repositories in the opencpi gitlab site, usually contributed by various third parties and, of course, component libraries can exist in other places that are internet except accessible or even privately inside other organizations, hopefully temporarily, before being contributed back component libraries frequently use available source codes from existing libraries when they are available as open source with acceptable licenses.

B

The table below is just a categorized set of possible components, some of which are available now some are under development and about to be contributed and others are awaiting development or contribution, so we'll wrap up by discussing. Why and when opencpi should be used and then a short roadmap of what's coming next for application developers what's interesting about opencpi is that it is designed and built to be ready for diverse hardware, diversity of hardware structures, hardware, processors and vendors.

B

So if you need to deploy on diverse hardware now, that's good- and you know the hardware you are deploying on. If you want to be ready for the hardware you don't know about, or you want to easily reconfigure your applications to move processing from one type of processor to another, depending on which has the heavy load or whether you have latency problems, then opencpi can be a valuable alternative for application development.

B

Also from a team and developer point of view, you have a common workflow as you develop component libraries and applications. So you are not switching tools and requiring new training and thus have easier movement of people between applications. Projects and systems.

B

Opencpi achieves this, since it has the commonality of the workflows and methods and terminology and concepts for component and application developers targeting diverse hardware for hardware owners and developers, there is a different set of benefits from opencpi device level. Drivers are widely applicable across platforms because the same chips are used in different systems from different vendors, and it is common for a new system to be enabled using drivers that already exist, which is the same model as embedded linux, where the developer of a new system using embedded linux would use existing drivers.

B

Also, there is a structured process for delivering hardware support because it is key to opencpi a lot of effort in the tools and documentation and packaging makes this process well defined.

B

There is a workshop later this week that will elaborate on that process also because the available component libraries are already heterogeneous. The new hardware platform usually has component libraries ready to be used and tested.

B

Finally, for small and new hardware vendors, you can avoid the time and expense of creating an sdk that is targeted for your own product line and instead simply use opencpi.

B

This is the short-term roadmap for opencpi for the rest of this year, and next year, open cpi 2.0 was recently released and going forward. There are multiple teams with multiple organizations that are improving and evolving opencpi, with the following major priorities: first, further gnu radio and gnu radio companion integration with opencpi.

B

What this means is building on the current dual mode, gnu radio companion, which all already allows building and running gnu radio flow graphs and open cpi applications, but they don't really mix together.

B

So the next major effort is a runtime integration, where applications can combine components and blocks from both frameworks.

B

On the hardware side, there are efforts to support more of the product line from edis more of the adi development and system on module products. More of the epic sdrs support for the rf sock technology from xilinx is under development and the cyclone 5 and stratix 10 based systems that are based on the intel fpgas are also under development.

B

We are always looking for ways to make applications ever more portable across diverse hardware, and there are a few improvements we will make in this area as well.

B

Finally, we are going to refresh the opencl support for graphics processors, which was previously done in opencl 1.2, and we want to update and refresh that for openc opencl 3.0 here are some useful internet addresses for getting more information about opencpi, and there are two workshops later this week at this conference, one is more of an introduction to using opencpi with gnu radio companion.

B

The other is an introduction to developing new hardware support for opencpi due to demand. Each workshop will be given three times and hopefully we now have some time for questions using the messaging set up by the conference. Thank you.