Proposed OpenPOWER Work Groups and Projects
|25G IO Interoperability Mode WG||Specification of a 25Gbps Operating Mode…||Member|
|Accelerator Work Group||PSL/AFU Interface Specification. OpenCL SDK to OpenPOWER Platform Interface…||Member|
|Academia Discussion Group||Information exchange among OpenPOWER members from Academia…||Member|
|Accelerated Application Ecosystem Requirements||Charter under development…||Member|
|Compliance Work Group||Architecture Compliance Definition specification (intended to be an OPF standard)…||Member|
|FSI Work Group||Develop OpenPOWER FSI Specification version 1.0 and version 2.0…||Member|
|Hardware Architecture Work Group||OpenPOWER profile of architecture…||Member|
|IO Work Group (OPIO)||I/O related specifications required for OpenPOWER System Design…||Member|
|Machine Learning Work Group (OPMLWG)||Provides a forum for collaboration to help define frameworks for the productive development and deployment of machine learning solutions…||Member|
|Memory Work Group||Define OpenPOWER Memory Bus (OPMB) functional interface to allow innovative Memory Function units integration to OpenPOWER systems….||Member|
|OpenPOWER Ready™ Work Group||Leadership and management of all aspects of the OpenPOWER Ready™ Program….||Member|
|Physical Science Work Group||Addresses the challenges of Physical Sciences projects by developing use cases….||Member|
|Potential Work Group Topics||Discussion group for suggestion and development of technical work group topics…||Open|
|Systems Software Work Group (open source)||LE Linux / KVM – OPAL Firmware – 63bit LE ABI
Linux on Power Architecture Platform Reference…
|Scalable Datacenter Architectures Discussion Group||This work group is headed by Eugen Schenfeld, IBM Watson Lab…||Member|
|Technical Work Groups||Parent work group to provide hierarchical grouping for all technical work groups….||Open|
|Work Group Chartering Sub-Committees||Parent work group to hierarchically hold work group chartering….||Open|
Note: Additional workgroups will be proposed by OpenPOWER Foundation Members and recommended to the OPF Board by the TSC.
25G IO Interoperability Mode Work Group
This work group will provide a forum to work out an interoperability mode for custom 25Gbps PHYs. This Work Group will be of limited duration and focused on the creation of a specification for a 25Gbps operating mode for custom high speed PHYs, including PHY electrical and PHY training via a Data Link (DL) layer. This specification will not be an implementation specification for a high speed PHY.
Accelerator Work Group
The Accelerator work group will be a persistent, standing group that defines, documents, manages, and maintains standards which define the interfaces between the processor and accelerator devices and their associated development tools. This includes hardware, firmware and any other software require for accelerators to operate within OpenPOWER compliant systems. It will also identify future requirements and propose innovations to the interfaces to enable advances in accelerator capabilities and work with other working groups as appropriate.
Academia Discussion Group
Discussion group for information exchange among OpenPOWER members from academia.
Accelerated Application Ecosystem Requirements
The proposed charter is presently being drafted with the following mission:The Accelerated Application Ecosystem Requirements Work Group (AccAppReq WG) will collect and disposition the list of tools, libraries, frameworks and other components/resources needed in the OpenPOWER software ecosystem to ensure that accelerated applications support OpenPOWER servers. These requirements will be collected from actual ISVs who either have or considered porting and/or developing on the platform.
Compliance Work Group
The OpenPOWER Compliance Work Group will define OpenPOWER key interfaces that need to be compliant in a standard specification of compliance and define how to measure and document compliance pre-silicon and post-silicon.
Subcommittees for each set of related key interfaces will be formed to address reference test harnesses and reference test suites. This will allow for focused effort by the experts and interested members of the related key interfaces. The importance of this Work Group is to be able to maintain software and hardware interoperability through following the compliance specifications.
FSI Work Group
The target of this work group is to provide a forum for work group (WG) members to define a Field Replaceable Unit Service Interface (FSI) interface specification that is suitable as an Open Power Foundation FSI standard for device control and monitoring. The FSI Specification work group will be a persistent work group to focus on establishing an OpenPOWER Foundation accepted and confirmed FSI interface specification.
The currently available IBM FSI specification will be reformatted, reviewed and eventually owned by the OpenPOWER FSI specification work group members as OpenPOWER FSI specification version 1.0. All FSI enhancements this work group identifies during the review process of OpenPOWER FSI specification version 1.0 will be defined and added to the OpenPOWER FSI specification version 2.0. This OpenPOWER FSI specification can be used by developers of FPGA, ASSP or ASIC components to integrate the FSI interface as an additional external interface like JTAG or I2C. This will enable the more seamless integration of these components into an OpenPOWER system and support the enhanced serviceability capabilities provided. A valuable example of this would be additional FSI onto a Baseboard Management Controller (BMC) component.
The work product from this work group is intended to eventually be published to the public
Hardware Architecture Work Group
This work group is a persistent WG focused on the ongoing development of OpenPOWER System Hardware Architecture Specifications. Specifications included in, but not limiting the scope will be the OpenPOWER Profile of the POWER ISA, the IO Device Architecture (IODA), and the Coherent Accelerator Interface Architecture (CAIA). The OpenPOWER Profile is defined as the subset of instructions and features of the POWER ISA required to support the OpenPOWER ecosystem. The IO Device Architecture describes the “host bridge” functions / interface support for IO Devices, for example PCIe Host Bridge. CAIA describes the interface to the Operating System (OS) by defining how the OS should work with a Coherent Accelerator Processor Interface (CAPI) Device attached tothe Power Service Layer (PSL).
IO Work Group (OPIO)
The OpenPOWER I/O Work Group is chartered with the goal of driving collaboration in enabling a rich I/O portfolio for OpenPOWER Systems. This work group will extend and complement related OpenPOWER work groups including HW Architecture, Software, and Compliance. Focus is on developing OpenPOWER I/O enablement guides and resources, collaboration, and communication. A major area of focus is on developing an OpenPOWER I/O information hub accessible to all stakeholders, and I/O related specifications required for OpenPOWER system design and I/O Enablement guides and tools. This group will collaborate with the compliance work group and others.
Machine Learning Work Group
The OpenPOWER Machine Learning Work Group provides a forum for collaboration that will help define frameworks for the productive development and deployment of machine learning solutions using OpenPOWER ecosystem technology.
As part of the ecosystem, the OPMLWG plays a crucial role in expanding the OpenPOWER mission. It focuses on addressing the challenges machine learning project developers are continuously facing by identifying use cases, defining requirements and extracting workflows, to better understand processes with similar needs and pain points. The working group will also identify and develop technologies for the effective execution on machine learning applications by enabling hardware (HW), software (SW) and acceleration across the OpenPOWER ecosystem.
Memory Work Group
The OpenPOWER Memory work group is a persistent, standing group that defines, documents, manages and maintains the interface requirements (protocol, timing, etc.) between the OpenPOWER Processor Memory Channel which provides a common intermediate interface to memory controllers that attach to physical memory. It will also identify which type of memory technology and ensure that the interface will be compatible, suitable with OpenPOWER Memory Bus. Since this work group affects the area of both hardware and software in the OpenPOWER ecosystem, it is expected that its activities will be related to the activities of the
- Compliance WG
- Industry standard body
- Hardware Development platform WG
- System Software WG
OpenPOWER Ready Work Group
Leadership and management of all aspects of the OpenPOWER Ready Program. Key aspects are the OpenPOWER Ready Definition and Criteria, review of OpenPOWER Ready requests, and outreach to encourage participation.
Physical Science Work Group
This Work Group aims at addressing the challenges of Physical Science projects by developing use cases, identifying requirements and extracting workflows, to better understand common workflows with related needs and pain points.
Potential Work Group Topics
Discussion Group for the suggestion and development of potential technical work group topics.
Systems Software WG (Open Source)
The Systems Software work group will serve as the stewards, incubators, and drivers (when feasible) of system software enablement for OpenPOWER Foundation hardware. As such, the work group will work to ensure the availability of all software required to boot, run, and manage Linux on OpenPOWER compliant systems. This includes platform firmware, virtualization environments, Linux itself, toolchain (compilers, core libraries, debuggers, etc.) and platform management software. This does not include software specifically used to enable end user application execution. The goal for all software is availability under an appropriate open source license.
Scalable Datacenter Architectures Discussion Group
This Work Group has been formed and is headed by Eugen Schenfeld, IBM Watson Research Lab.
Technical Work Groups
Parent Work Group to provide hierarchical grouping for all the technical working groups. These groups will be managed by the TSC. The charters for these work groups are created by the chartering subcommittees.
Work Group Chartering Sub-committees
This Work Group is set up as a parent or root work group to hierarchically hold Work Group chartering sub-committees. All work will be handled at the chartering sub-committees.