OpenRF Working Group 2 was established to develop a common hardware abstraction layer (HAL) enhancing the transceiver/modem and RF front end interface. Working Group 2 co-chairs Gordon Huang, MediaTek, and Surya Pappu, Qorvo, met with us to provide an overview of the working group’s mission, principal goals and also provide us with a sense of what Working Group 2 has planned for the future.
Working Group 2’s mission is to develop a common hardware abstraction layer – or HAL. What is the HAL and what are you doing to accomplish this?
Working Group 2 is working on establishing a standardized version of interoperable software interfaces that can be extended to any product and any future product. Our goal is to design the software so that it can be integrated pretty easily with minimal effort onto a platform. Our main deliverable is a re-usable/portable software interface to the lower layer driver. What that means is that anybody who uses this software package specific to a particular front-end device will be able to easily integrate it into the system.
From a chipset point of view, the process is fairly difficult as there is no standard. Front-end devices are very diverse and there’s no regular pattern that we can apply to easily integrate them. There are a lot of exceptions, and thus there are a lot of workarounds. With this particular working group charter, we are trying to standardize in the sense that all the functionalities are still there, but in a way that there is a regular pattern, a regular way of integrating it without losing the competitiveness of the front-end device itself.
Before we started working on the OpenRF specification, the front-end module vendors found it challenging to work around the different programming models of the different RFICs. So, what we are striving towards is for all the chipset vendors that are part of OpenRF, our programming model will provide an abstraction of the chipset so that when we develop the driver for one of our front-end modules, it is highly portable because of the programming model being standardized by Working Group 2.
From an industry point of view, what will a standardized HAL help accomplish?
The OEMs have their choices of putting whichever components they need to put on their SKU. For example, Japan, North America, Latin America, and the EU can contain very different sets of front-end devices. The problem is that without standardization, each one of them has its own unique characteristics. This means that the integration efforts (time and resources) required to put a product together is actually quite large and usually very complex, especially when it comes to customization. So, the need, at least from the chipset and the OEM point of view, is to lower the risk of making mistakes and also create a faster turnaround time to get the device all the way to where we can actually test and deploy it. The key benefit of the HAL is a standardization that allows faster deployment, and lower error rates without compromising all of the functionalities needed by each market.
From a front-end perspective, when we have the same front-end component for different chipsets, we have to develop different drivers. This means that front-end vendors have to consider the different programming models and interfaces provided by these chipsets. If you develop a driver for one chipset and it’s not in the current model you are developing a driver for, it is going to have to be replicated across all the chipsets that are used by the OEMs. It is a very repetitive process. The reusability portion of the HAL is actually quite significant in the sense that now this particular driver can be used by whomever uses this particular front-end device, and they will be able to reuse the software. For example, if it’s a mid-high band device, the driver can be used across all the SKUs or even across projects. This is quite a tremendous savings in terms of the efforts that need to be put into developing the product.
By striving to standardize this product programming model and also having this HAL as a deliverable, we can help reduce the driver development and integration time from a front-end perspective. The maintenance ability, integration effort reduction in errors, and portability are the driving factors for Working Group 2 right now.
Is this included in the Phase 1.0.0 specification or is this going to be included in a different version?
For the Phase 1.0.0 specification, we have been working to publish the initial architecture and set up the framework for source code and header files. We also are setting up the initial programming guide. Phase 1.0.0 is not really in a deployable state, however, because it is laying the groundwork, getting everybody to be on the same page, and recognizing all the potential benefits.
In future releases, we are working towards bringing the HAL into a deployable state. When we release the next phase of the specification, that release of the HAL will be in a deployable state in the sense that the front-end vendors can take the templates and develop drivers. They will be able to start working with chipsets to integrate with the new paradigm.
How will testing impact the HAL framework?
We are also planning a new unit and integration test suite on our expectation that once the HAL is in a deployable state, all the members of OpenRF will use the HAL programming model to develop drivers. Once they develop the drivers, the idea behind the unit and integration test suite is that they will be able to test the drivers before releasing them to the chipset reference design or OEMs. This will help increase the confidence level in the driver that is being delivered to the OEMs or the reference design projects.
The testing aspect is really important in the industry. For example, if you take the android or iOS frameworks there are device driver developers in those frameworks for cameras or sensors. Those frameworks have these kinds of test suites that allow new device drivers to be tested before being pushed into the cloud. There is the same need with the HAL. The HAL is a software framework, so it goes without saying that there has to be a test suite accompanying any activity that takes place in a software framework environment. These unit and integration tests are something very similar, but of course, the scope is very restricted in the sense that it is meant for the OEMs and reference design and then these will be exercised by the front-end module driver developers.
What’s next for the group after the release of the Phase 1.0.0 specification?
We are working with other OpenRF Working Groups to come up with a reference design – a mock front-end device. It basically goes through a process of how we define, then goes from a definition to how we actually implement the lower layer driver. When we exercise this whole process, we give the front-end and also the RFIC folks a visualization of how these codes are realized. So, this is one thing that we’re planning to be able to deliver next time. The goal is to base the mock front-end device on a well-designed reference design that’s very close to a real product and then they can take it as a baseline.
We are also looking at the unit test itself to save time when the front-end folks have a specific design that they need to realize. They also have to go through a process of unit testing and integration. We are looking at whether or not they need to actually go ahead and define their own unit and test process or whether we can actually do something to save them more time by providing a basic framework that they can build on.
In the near term, the focus of Working Group 2 will be centered around operation optimization and developing a unit & test integration suite. As the ecosystem grows, there will be many other things that come along that we will begin to address.