OpenRF Working Group 1 was established to create a register map framework, leveraging industry standards to maximize configurability and effectiveness of the RF front-end. Working Group 1 co-chairs Jin Cho and David Southcombe provide an overview of the working group’s mission, principal goals and a look toward the future.
What are the goals and mission of Working Group 1? What are you working to accomplish?
The primary effort of Working Group 1 is to minimize the software customization front-end, which will reduce the time to market and reduce the R&D cost for the OEMs. OEMs won’t have to make adjustments just to get the common features to work between the different vendors. The register map is a template that defines where these features will go and what registers are going to control what feature. Establishing the register map in this way allows the software to be more compatible because the registry maps will be more predictable.
What is the need for an OpenRF Register Map?
There are register maps for products that are in the market today, and each vendor has a slightly different register map. As a result, OEMs have to navigate that and they have to provide software approaches, different software rights, and different numbers of rights to achieve the same response from these different vendor modules. That stems from the industry standard for the interface defines the required registers for the protocol control.
RF front-end defines what registers it needs to control the protocol, but leaves the module control registers to the user, and calls those “user-defined registers.” That’s the space where OpenRF is coming in — to define those “user-defined registers” in a structured template format. In today’s market, there’s not a lot of guidance and the guidance that does come is often late in the development cycle of these products, meaning RF vendors have to spin new wafers, which is both time and money, just to make the updates try to achieve a little bit more compatibility for a given OEM.
Within the OpenRF Register Map, is there a way for vendors to implement specific features for a particular OEM, or is everything defined by the Register Map?
The OpenRF register maps create device classes, and within each device class is a template. That template defines a list of functions and how we’re grouping those functions. There’s a set of registers defined for each of those functions, as well as registers to define differentiating features. So, if a vendor has something that’s unique to their part and is a key differentiator, there are areas of the register map that are allocated for control of those type of features. This provides a common structure and allows the balance between structure and differentiation. That type of approach is going to be present in the register maps, in the hardware extraction layer, and then the front-end modules as well.
What are some other ways OpenRF is helping manage front-end complexity?
The approach has been to allow the one-time loading of supplier-specific software, sometimes called the static configuration. This would occur at power-up when the parts are first being turned on, and it allows for a large number of rights to be sent to each of the front-end modules if the supplier chooses to implement it that way. This approach allows for more differentiating features without putting a burden on the timing that actually has to go on within the slots or frames or symbols as you’re trying to control the complexity of this front-end.
How does OpenRF determine which features are going to be included in the Register Map?
Working Group 1 is accommodating the latest industry features; these features are determined by our members. They have provided a lot of input via Working Groups 2 and 3. They are working with our members to identify certain approaches or features; members are saying, “This is what we’re seeing and this is what we want to work together to standardize.” And our member chipset vendors are saying, “These are the features we’re going to need; let’s identify how we want to control them.” So it’s truly a collaborative effort to work within the industry and identify the features.
As a result, we have a template that says if you have a feature, here’s where you control it within the register map. And if you have something that is unique toward that function, the template can show you where in the register map your allocated area is to control that. This minimizes the number of software frameworks across all the tiers of products, and it’s in Release 1.0.0 for the OEMs and manufacturers.