Openpower Ready™ November 13, 2017 Revision 2.0 - PRD

REVIEW DRAFT

www.openpowerfoundation.org OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

All capitalized terms in the following text have the meanings assigned to them in the OpenPOWER Intellectual Property Rights Policy (the "OpenPOWER IPR Policy"). The full Policy may be found at the OpenPOWER website or are available upon request. REVIEW DRAFT - This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OpenPOWER, except as needed for the purpose of developing any document or deliverable produced by an OpenPOW- ER Work Group (in which case the rules applicable to copyrights, as set forth in the OpenPOWER IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OpenPOWER or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis AND TO THE

REVIEW DRAFT - MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE OpenPOWER Foundation AS WELL AS THE AUTHORS AND DEVELOPERS OF THIS STANDARDS FINAL DELIVERABLE OR OTHER DOCUMENT HEREBY DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES, DUTIES OR CONDITIONS OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR PURPOSE, OF ACCURACY OR COMPLETENESS OF RESPONSES, OF RESULTS, OF WORKMANLIKE EFFORT, OF LACK OF VIRUSES, OF LACK OF NEGLIGENCE OR NON-INFRINGEMENT.

OpenPOWER, the OpenPOWER logo, and openpowerfoundation.org are trademarks or registered trademarks of OpenPOWER Foundation, Inc., registered in many jurisdictions worldwide. Other company, product, and service names may be trademarks or service marks of others.

Abstract

REVIEW DRAFT - OpenPOWER Ready™ is a mark used by the OpenPOWER Foundation to enable OpenPOWER ecosystem product developers to indicate that a product has been shown / demonstrated to meet a minimum set of characteristics and should be interoperable with other OpenPOWER Ready products. This document defines the meaning of OpenPOWER Ready™ and it's different categories.

This document is a Standard Track, Work Group Specification work product owned by the OpenPOW- ER Ready Workgroup and handled in compliance with the requirements outlined in the OpenPOW- ER Foundation Work Group (WG) Process document. It was created using the Master Template Guide version 1.0.0. Comments, questions, etc. can be submitted to the public mailing list for this document at . REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation ii Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

Table of Contents

Preface ...... vi 1. Conventions ...... vi 2. Document change history ...... vii 1. Introduction ...... 1 1.1. OpenPOWER Ready™ Mark ...... 1 1.2. Demonstrating OpenPOWER Ready ...... 2 1.3. Requesting a Product be Included on the OpenPOWER Ready List ...... 2 REVIEW DRAFT - 1.4. Requesting License to display the OpenPOWER Ready Mark ...... 3 1.5. Publication of OpenPOWER Ready Products ...... 3 1.6. Scope ...... 3 2. OpenPOWER Ready System ...... 4 2.1. ISA Profile rev 1.0.0 based systems ...... 4 2.2. ISA Profile rev 2.0.0 based systems ...... 5 2.3. Trusted Boot and Secure Boot ...... 7 3. OpenPOWER Ready Software ...... 8 3.1. OpenPOWER Ready Criteria for Operating Systems ...... 8 3.2. OpenPOWER Ready Criteria for the Toolchains ...... 8 3.3. OpenPOWER Ready Criteria for Application ...... 8 4. OpenPOWER Ready I/O Adapter ...... 9

REVIEW DRAFT - 4.1. PCIe® Requirements ...... 9 4.2. Software Requirements ...... 9 4.3. OpenPOWER Ready Functional Test Requirements ...... 10 4.4. SAN/Storage Interoperability ...... 11 4.5. Direct Attached Storage Interoperability ...... 11 5. OpenPOWER Ready CAPI ...... 12 5.1. OpenPOWER Ready Criteria for CAPI Adapters ...... 13 5.2. OpenPOWER Ready Criteria for CAPI Applications ...... 14 6. OpenPOWER Ready CAPI SNAP ...... 16 6.1. OpenPOWER Ready Criteria for CAPI SNAP Solutions ...... 17 7. OpenPOWER Ready OpenCAPI™ 3.0 ...... 18 7.1. OpenPOWER Ready Criteria for OpenCAPI 3.0 Adapters ...... 18 7.2. OpenCAPI 3.0 Applications ...... 19 REVIEW DRAFT - 8. OpenPOWER Ready System Support Components ...... 20 A. OpenPOWER Foundation overview ...... 21 A.1. Foundation documentation ...... 21 A.2. Technical resources ...... 21 A.3. Contact the foundation ...... 22 REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation iii Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

List of Figures

1.1. OpenPOWER Ready Mark with Black Background ...... 1 1.2. OpenPOWER Ready Mark with White Background ...... 1 2.1. OpenPOWER System ...... 4 5.1. OpenPOWER CAPI Solution ...... 12 6.1. CAPI SNAP Components ...... 16 7.1. OpenPOWER OpenCAPI 3.0 Solution ...... 18 REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation iv Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

List of Tables

4.1. Required Software Testing ...... 9 REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation v Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

Preface 1. Conventions

The OpenPOWER Foundation documentation uses several typesetting conventions. Notices REVIEW DRAFT - Notices take these forms:

Note

A handy tip or reminder.

Important

Something you must be aware of before proceeding.

REVIEW DRAFT - Warning

Critical information about the risk of data loss or security issues. Changes

At certain points in the document lifecycle, knowing what changed in a document is important. In these situations, the following conventions will used.

• New text will appear like this. Text marked in this way is completely new.

• Deleted text will appear like this. Text marked in this way was removed from the previous version and will not appear in the final, published document. REVIEW DRAFT -

• Changed text will appear like this. Text marked in this way appeared in previous versions but has been modified. Command prompts

In general, examples use commands from the Linux operating system. Many of these are also common with Mac OS, but may differ greatly from the Windows operating system equivalents.

For the Linux-based commands referenced, the following conventions will be followed:

Any user, including the root user, can run commands that are prefixed with the $

REVIEW DRAFT - $ prompt prompt.

# prompt The root user must run commands that are prefixed with the # prompt. You can also prefix these commands with the sudo command, if available, to run them. Workgroup Specification OpenPOWER Foundation vi Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

Document links

Document links frequently appear throughout the documents. Generally, these links include a text for the link, followed by a page number in parenthesis. For example, this link, Preface [vi], references the Preface chapter on page vi. 2. Document change history

This version of the guide replaces and obsoletes all earlier versions. REVIEW DRAFT -

The following table describes the most recent changes:

Revision Date Summary of Changes August 17, 2017 • Rev 2.X - Working Draft of of changes • Updated section 5 to include Power 9 criteria November 13, 2017 • Rev 2.0 - Public Review Draft June 6, 2017 • Rev 2.X - Working Draft of of changes • Updated Intro to reflect changes to submission process via web automation March 25, 2016 • Rev 1.0 - Approval version • Cleaned URLs March 23, 2016 • Rev 0.12 Removed 2016 from title. • Added link to TMLA text REVIEW DRAFT - • Added links to request document templates • modified section 1.6 Scope March 4, 2016 • 2016 Rev 0.10 Updated intro to encourage broad participation. • 2016 Rev 0.9 Updated system OS criteria March 3, 2016 • Change title to 2016 and change rev to 0.8 • Added trademark symbols • Removed "OpenPOWER Intention" • Added additional miscellaneous category February 2, 2016 • Many changes from review of 0.0.6 January 27, 2016 • Many changes from review of 0.0.5 by WGs and BOD January 20, 2016 • Added OpenPOWER Ready Graphics January 15, 2016 • Added SW chapter • Updated CAPI chapter per Accelerator WG Feedback

REVIEW DRAFT - • Added more details on intent and process in intro. • Added references into IO chapter. December 8, 2015 • Added more details on intent and process in intro. • Added chapter on OpenPOWER Ready CAPI. • Fixed improper abbreviations of OpenPOWER Foundation, OpenPOWER Ready, and OpenPOWER Intent October 3, 2015 • Initial draft based on input from OPIO and DEVPLAT Workgroup REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation vii Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

1. Introduction The OpenPOWER Ready™ program is used by the OpenPOWER Foundation to enable OpenPOW- ER ecosystem product developers to indicate that a product has been shown / demonstrated to meet a minimum set of characteristics and should be interoperable with other OpenPOWER Ready products. This document defines the meaning of OpenPOWER Ready™ and it's different categories.

OpenPOWER ecosystem participants who have items or products they are interested in marking should follow the appropriate criteria described below. Other elements of the entire OpenPOWER REVIEW DRAFT - platform solution which do not fit into the current criteria are all invited to self-confirm and deploy the OpenPOWER Ready badge.

Solution components that submit a request as described in Section 1.3, “Requesting a Product be Included on the OpenPOWER Ready List” [2] will automatically be listed on the OpenPOWER Foundation OpenPOWER Ready List.

Organizations wishing to mark a solution component must receive license to display the OpenPOW- ER Ready mark. See Section 1.4, “Requesting License to display the OpenPOWER Ready Mark” [3]. 1.1. OpenPOWER Ready™ Mark REVIEW DRAFT - The OpenPOWER Foundation has established OpenPOWER Ready™ as a special badge or mark used by an OpenPOWER ecosystem component producer/developer to attest that a specific component has been shown to satisfy the criteria defined in a specific version of this document. The criteria has been defined to increase the likelyhood components bearing the mark are compatible.

The mark is available for any entity interested in providing components/products to the OpenPOW- ER ecosystem. Combined with an OpenPOWER Foundation membership, companies and other entities can make a strong statement about their support of the OpenPOWER technology as an alternative to other server solutions. Entities providing products that are OpenPOWER Ready are encouraged to join the OpenPOWER Foundation.

Figure 1.1. OpenPOWER Ready Mark with Black Background REVIEW DRAFT -

Figure 1.2. OpenPOWER Ready Mark with White Background REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation 1 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

1.2. Demonstrating OpenPOWER Ready

An entity desiring to demonstrate a product or solution satisfies the respective criteria may do so in one of the following ways:

• Self assessment. • Third Party assessment. • Attend OpenPOWER PlugFest. REVIEW DRAFT - The OpenPOWER Foundation may sponsor OpenPOWER Plugfests to provide a convenient forum for companies to meet and demonstrate compatability and interoperability. 1.3. Requesting a Product be Included on the OpenPOWER Ready List

Evidence that the criteria are met must be provided by the requesting entity.

Each entity requesting a product be included in the OpenPOWER Ready list must provide the following information regarding the specific product or component to the OpenPOWER Foundation via the REVIEW DRAFT - online OpenPOWER Ready Request.

Upon receipt of a request containing the required information the OpenPOWER Foundation will confirm receipt of the request via email. After completeness of the request is reviewed by the OpenPOWER Foundation the Foundation will respond via email regarding the status of the OpenPOWER Ready Request.

Request Information

• Company • Requester / Contact Name • Contact email address REVIEW DRAFT - • Contact phone number (optional) • Product / Component Designator (unique name or label) • Short product / component description • Product / component information URL • Keywords (comma separated) to help an interested party search for this product. (optional) Keywords that repeat information are not necessary. Instead, broader categories and alternate industry terms are very helpful. • Version of this OpenPOWER Ready Document used for the criteria. Note: It is recommended that the latest version be used. However, a vendor may select a previous level of the criteria. • Product / component category (System, IO, CAPI, Operating System, Application, System Support Component)

REVIEW DRAFT - • Ready Criteria Assessment: Describe how the product fulfills the criteria defined for the selected product catagory / catagories in this document. • Image / graphic for inclusion with the description (Optional).

Workgroup Specification OpenPOWER Foundation 2 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

1.4. Requesting License to display the OpenPOWER Ready Mark

The OpenPOWER Foundation requires an agreed to trademark license agreement (TMLA) to display the mark. Once the TMLA is agreed to and logged the OpenPOWER Ready Mark may be displayed in accordance with the guidelines.

Reference versions of the OpenPOWER Ready™ TMLA and usage guidelines maybe reviewed at: REVIEW DRAFT - • TMLA: http://openpowerfoundation.org/?resource_lib=openpower-ready-tmla • Usage Guidelines: http://openpowerfoundation.org/?resource_lib=openpower-ready-tmla-usage- guidelines

During completion of the online OpenPOWER Ready Request the submitter will have three options with regard to the TMLA.

TMLA Options:

• Submit the request without a TMLA - The approved product may not display the OpenPOWER Ready Mark • Review the TMLA and Accept via "click-through" REVIEW DRAFT - • Download the TMLA for signature, Upload the signed TMLA.

Note: The approved product will be listed on the OpenPOWER Ready List regardless of TMLA option selected. 1.5. Publication of OpenPOWER Ready Products

The OpenPOWER Foundation will publish a list of components that have been shown to be OpenPOWER Ready. The OpenPOWER Ready List is located on the OpenPOWER Foundation website. This list will be updated regularly. All approved products will be automatically included in the

REVIEW DRAFT - OpenPOWER Ready List. 1.6. Scope

Use of the OpenPOWER Ready mark by OpenPOWER ecosystem product developers or inclusion on the OpenPOWER Ready List indicates that a product has been shown / demonstrated to meet a minimum set of characteristics and should be interoperable with other OpenPOWER Ready products.

The OpenPOWER Ready Mark does not ensure that products bearing the OpenPOWER Ready mark are interoperable, compatible, or suitable for the indicated purpose. In addition, it is the respon- sibility of the vendor to self-confirm compliance with necessary specifications and regulations such

REVIEW DRAFT - as but not limited to IEEE® 802.3™, PCIe® 3.0, RoHS (Restrictions of Hazardous Substances), etc.

Workgroup Specification OpenPOWER Foundation 3 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

2. OpenPOWER Ready System

This chapter covers the concept of OpenPOWER Ready from a system perspective. The following graphic Figure 2.1, “OpenPOWER System” [4] provides an abstracted view of a notional OpenPOWER system and the key interfaces that need to be considered.

Figure 2.1. OpenPOWER System REVIEW DRAFT -

REVIEW DRAFT - Requesters of OpenPOWER Ready with a "Product / component category" of System should include in the "product / component description" indication of one of:

1. ISA Profile rev 1.0.0 based systems or 2. ISA Profile rev 2.0.0 based systems.

In addition, if the system product satisfies Trusted Boot and Secure Boot this should also be included. 2.1. ISA Profile rev 1.0.0 based systems

The following describes the key attributes required for a system based on an OpenPOWER ISA

REVIEW DRAFT - Profile rev 1.0.0 chipset to be OpenPOWER Ready.

1. OpenPOWER ISA Profile processor Chipset. Note

For OpenPOWER ISA Profile V1.0.0 this means POWER8™, POWER8 with NVIDIA® NVLink™, or CP1 and at least one Centaur memory buffer with memory

2. Firmware to initialize the hardware is a modest derivative of the OpenPOWER Abstraction Layer (OPAL) FirmWare base, with no firmware API/ABI changes that have not been accepted upstream.

Developers are encouraged to contribute changes to the OPAL Firmware community as it makes REVIEW DRAFT - sense for their business so that the community can help develop and maintain their platform.

Platform vendors should remember to ensure a new and unique platform name in the device tree.

Workgroup Specification OpenPOWER Foundation 4 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

3. At least one boot device. Storage or PXE Network boot.

4. Must be able to install and run a current LTS (Long Term Support) version of Ubuntu® Server. At time of writing, Ubuntu® Server 14.04 LTS and/or Ubuntu® Server 16.04 LTS. Ubuntu in this context is an open source little endian OS based on the Linux® kernel, referred to as 'ubuntu server ppc64el' on official Ubuntu mirrors and archives.

It is strongly suggested that in addition to the most current LTS version of Ubuntu® Server, SLES™, RedHat® Enterprise Linux (RHEL), Debian®, CentOS™, Fedora™, and/or openSUSE™ be shown to operate. REVIEW DRAFT - 5. System must successfully run an exerciser application. The exerciser application should be open source, compilable with open tools, and provide some output which can indicate functionality. Ideally, it would run against the "core I/O", run SMP, and provide output in a way that indicates some performance of the complete systems (procs and memory).

SYSBENCH is an example of such an exerciser.

HTX is an example of such an exerciser.

6. PCIe® bus should support PCIe gen 1.0, 2.0 and 3.0 adapters.

7. A boot management chip to manage the Power On Reset (POR) and initial Program Load (IPL) REVIEW DRAFT - is needed.

• Baseboard Management Controller (BMC) is a possible option

For Example: ASPEED® AST2400

8. A system level XML file as input to the OpenPOWER Build process for host firmware.

Due to the level of details required in the XML, it is recommended to use the Open Power Serverwiz. This tool is available on github at https://github.com/open-power/serverwiz

9. PNOR, VPD, Thermal and Power devices. See https://github.com/open-power/docs for more

REVIEW DRAFT - information regarding OPAL FirmWare expectations. 2.2. ISA Profile rev 2.0.0 based systems

The following describes the key attributes required for a system based on an OpenPOWER ISA Profile rev 2.0.0 chipset to be OpenPOWER Ready.

1. OpenPOWER ISA Profile processor Chipset.

Note

For OpenPOWER ISA Profile V2.0.0 this means POWER9™, REVIEW DRAFT - 2. Firmware to initialize the hardware is a modest derivative of the OpenPOWER Abstraction Layer (OPAL) FirmWare base, with no firmware API/ABI changes that have not been accepted upstream. Specifically, Firmware must be a modest derivative of op-build v2.0 which may be found at OpenPOWER Firmware Build Environment: https://github.com/open-power/op-build Workgroup Specification OpenPOWER Foundation 5 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

Developers are encouraged to contribute changes to the OPAL Firmware community as it makes sense for their business so that the community can help develop and maintain their platform.

Platform vendors should remember to ensure a new and unique platform name in the device tree.

3. At least one boot device. Storage or PXE Network boot.

4. Must be able to install and run a current LTS (Long Term Support) version of Ubuntu® Server. Ubuntu in this context is an open source little endian OS based on the Linux® kernel, referred to REVIEW DRAFT - as 'ubuntu server ppc64el' on official Ubuntu mirrors and archives.

5. System must successfully run an exerciser application. The exerciser application should be open source, compilable with open tools, and provide some output which can indicate functionality. Ideally, it would run against the "core I/O", run SMP, and provide output in a way that indicates some performance of the complete systems (procs and memory).

SYSBENCH is an example of such an exerciser. REVIEW DRAFT - HTX is an example of such an exerciser.

The recommended test framework that firmware and system must pass is located at OpenPower Test Framework: https://github.com/open-power/op-test-framework

6. PCIe® bus should support PCIe gen 1.0, 2.0, 3.0, and 4.0 adapters.

7. A boot management chip to manage the Power On Reset (POR) and initial Program Load (IPL) is needed.

• Baseboard Management Controller (BMC) is a possible option REVIEW DRAFT - For Example: ASPEED® AST2400

Note

It is recommended that the BMC firmware be based on OpenBMC. Information about OpenBMC may be found at https://github.com/openbmc/openbmc.

8. A system level XML file as input to the OpenPOWER Build process for host firmware.

Due to the level of details required in the XML, it is recommended to use the Open Power Serverwiz. This tool is available on github at https://github.com/open-power/serverwiz

REVIEW DRAFT - 9. PNOR, VPD, Thermal and Power devices. See https://github.com/open-power/docs for more information regarding OPAL FirmWare expectations.

Workgroup Specification OpenPOWER Foundation 6 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

2.3. Trusted Boot and Secure Boot

Trusted Boot is the measurement (hashing) of system firmware boot components and the creation of secure cryptographic artifacts that unambiguously demonstrate that particular firmware has been executed by the system. Trusted Boot artifacts can be used to remotely verify system integrity or to seal secrets to that they are only available after certain firmware has executed. Secure Boot is the cryptographic signing and verification of firmware boot components, failure of which is flagged for system administrator investigation and action, including logging an error and halting the system boot. Secure Boot prevents the system from executing either accidentally or maliciously modified REVIEW DRAFT - firmware.

To achieve Trusted Boot and Secure Boot OpenPOWER Readiness, a system must:

1. Include a Trusted Platform Module (TPM), a small embedded security processor that conforms to the Trusted Computing Group TPM 2.0 specification that can securely store data.

2. Create a firmware measurement log and extend appropriate measurements to PCRs in the TPM as documented in the op-build source code and design documentation when in Trusted Boot mode.

3. Be able to store firmware components in Processor NOR (PNOR) flash memory that are packaged and signed in accordance with the op-build source code and design documentation,

REVIEW DRAFT - to support secure boot of firmware

4. Reserve a region in PNOR for storing OS-specific signatures and keys, to support secure boot of the target Operating System.

5. Provide a platform-specific method to assert physical presence to bypass Secure Boot for system recovery.

In order to use existing OpenPOWER firmware support:

1. The TPM processor should be compatible with the Nuvoton NPCT 650 and should be connected to the CPU via an I2C bus.

REVIEW DRAFT - 2. Firmware components must be packaged and signed in accordance with the op-build source code and design documentation. The foregoing applies to systems satisfying OpenPOWER Foundation Section 2.1, “ISA Profile rev 1.0.0 based systems” [4] or Section 2.2, “ISA Profile rev 2.0.0 based systems” [5].

Systems capable of supporting Trusted Boot and Secure Boot for firmware and operating system integrity verification and protection are recommended. REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation 7 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

3. OpenPOWER Ready Software

The OpenPOWER Ready mark also applies to software applications and operating systems. 3.1. OpenPOWER Ready Criteria for Operating Systems

REVIEW DRAFT - OpenPOWER Ready operating system distributions must meet the following criteria.

1. Demonstrated execution on at least one OpenPOWER Ready system. The operating system would be tested on multiple systems. The operating systems must satisfy the vendor test suite. 3.2. OpenPOWER Ready Criteria for the Toolchains

OpenPOWER Ready Toolchain must meet the following criteria.

1. The OpenPOWER Ready toolchain should satisfy the 64-Bit ELF V2 ABI Specification found

REVIEW DRAFT - here; https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power- architecture For reference information see the OpenPOWER ELFv2 ABI Compliance TH/TS Specification. It can be found here; https://openpowerfoundation.org/?resource_lib=elfv2-abi- compliance-thts-specification 3.3. OpenPOWER Ready Criteria for Application

OpenPOWER Ready applications must meet the following criteria.

1. The application must demonstrate execution on an OpenPOWER Ready operating system

REVIEW DRAFT - Distro per Section 3.1, “OpenPOWER Ready Criteria for Operating Systems” [8].

2. The application must be compiled and built using an OpenPOWER Ready operating system Distro toolchain per Section 3.2, “OpenPOWER Ready Criteria for the Toolchains” [8]. REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation 8 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

4. OpenPOWER Ready I/O Adapter

An IO Adapter that is OpenPOWER Ready has met the criteria defined in this section. 4.1. PCIe® Requirements

POWER8 OpenPOWER Ready I/O devices intended for plugging into PCIe Gen3 slots should be PCI-SIG® PCIe 3.0 Specification compliant. It is important to note that PCIe 3.0 standard supports REVIEW DRAFT - PCIe 1.0 and 2.0 devices as well. PCIe devices that are PCIe 1.0 or 2.0 compliant, satisfy this OpenPOWER Ready criteria.

POWER9 OpenPOWER Ready I/O devices intended for plugging into PCIe Gen4 slots should be PCI-SIG® PCIe 4.0 Specification compliant. It is important to note that PCIe 4.0 standard supports PCIe 1.0, 2.0 and 3.0 devices as well. PCIe devices that are PCIe 1.0, 2.0 or 3.0 compliant, satisfy this OpenPOWER Ready criteria.

The device is required to be tested in one of the OpenPOWER Ready systems and the results from the test should be made available. Functional tests described below cover PCIe in addition to device functions.

REVIEW DRAFT - 4.2. Software Requirements

In addition to a Linux on POWER LE (LoP-LE) mode device driver for the device, additional software is frequently required (see the table below for examples). Required software for the claimed functions of the OpenPOWER Ready I/O adapter must be available to the consumer of the device under OSI approved license or commercial license.

OpenPOWER Ready requires test of the offered software in an OpenPOWER configuration. The software test is part of the functional test requirements described below.

Table 4.1. Required Software Testing

REVIEW DRAFT - Software Requirement Recommendation Device Driver 1. A LoP-LE Driver is required. Open Source License is Driver should follow Linux on POWER desired. Device Driver Porting Guide

2. Successful Functional Test on at least one of the LoP-LE Ubuntu 17.04 is recommended initial Distributions (Ubuntu, RHEL, SuSE, PowerKVM™, etc.) POWER9 support distro Boot OPAL Firmware and petitboot as of op-build v1.7 (or later). Online Documentation available for Additional device drivers may be added to enable boot support Driver and Utilities support in OPAL/ off these devices. Petitboot OPAL/Petitboot GIT hub. Serviceability and LE-LoP based utilities for device Diagnostics, FW update, and These utilities should target open Management. Configuration. source tools e.g. ethtool. Vendor toolset ported to LE-LoP is acceptable. Storage Management LE-LoP RAID Configuration Utilities and Storage Enclosure Package RAID configuration utilities Management. as a petitboot blugin in addition to

REVIEW DRAFT - being made available for LoP linux distros SAN Storage Software. LE-LoP MPIO and HBA/SAN Management Software is required Should target open source tools e.g. for FC/FCoE/ISCSI HBAs Linux MPIO. Vendor toolset ported to LE-LoP is acceptable.

Workgroup Specification OpenPOWER Foundation 9 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

Software Requirement Recommendation Advanced Networking LE-LoP RDMA/OFED, DPDK, OpenOnload, iSCSI, OVS, Stacks are open source but require Overlay Networking etc. is required for devices claiming support porting, tuning and productization for of the advanced stacks. the devices.

Devices claiming support of an "advanced stack" should have the stack's respective open source ported, tuned and productized for the devices.

REVIEW DRAFT - 4.3. OpenPOWER Ready Functional Test Requirements

I/O Device functional test completion is required with the following test coverage. The IO Adapter owner is responsible for all functional testing. Responsible parties for test competition are listed in Section 1.2, “Demonstrating OpenPOWER Ready” [2]

1. OpenPOWER PCIe compatibility.

PCIe Adapters may be tested in PCIe-G4, PCIe-G3, PCIe-G2 or PCIe-G1 mode based on the capabilities of the adapter. Test results must document the supported mode(s). REVIEW DRAFT - a. IO Adapters should comply with PCI-SIG requirements. b. IO adapters must successfully operate in an OpenPOWER Ready System

2. Device specific function tests.

a. Device specific tests vary based on device type.

Example test plans for Ethernet Adapters and Direct Attached Storage are provided in the following workgroup notes from the OpenPOWER Foundation IO Workgroup: EN Functional Tests Spec and DAS Functional Test Spec.

REVIEW DRAFT - b. Device specific testing is required in an OpenPOWER Ready system.

3. Stress tests

a. These tests verify device under heavy load. b. These tests are required to be completed in an OpenPOWER Ready System.

4. Performance Tests

a. Performance results from device specific benchmarks should be provided. b. These tests are required to be completed in an OpenPOWER Ready System.

REVIEW DRAFT - 5. Error reporting and recovery

a. Error reporting and recovery varies with device types b. These tests are required to be completed in and OpenPOWER Ready System.

Workgroup Specification OpenPOWER Foundation 10 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

4.4. SAN/Storage Interoperability

OpenPOWER Ready does not have specific criteria for SAN (FC, FCoE or iSCSI) Interoperability tests but most SAN Storage Products and SAN Switches require interoperability tests. These tests are beyond the scope of OpenPOWER Ready requirements but are highly desired because these are required for many solutions. 4.5. Direct Attached Storage Interoperability REVIEW DRAFT - OpenPOWER Ready does not have specific criteria for system / storage expansion interoperability tests. Most configurations require test e.g. SAS HBAs connecting to SAS Expander / Storage enclosures. These tests are not part of OpenPOWER Ready criteria but are highly desired because these are required for many solutions. REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation 11 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

5. OpenPOWER Ready CAPI

The OpenPOWER Ready mark also applies to CAPI PCIe adapters and solutions built using them. The following graphic Figure 5.1, “OpenPOWER CAPI Solution ” [12] provides an abstracted view of a notional OpenPOWER CAPI solution and its key components.

Requesters of OpenPOWER Ready with a "Product / component category" of CAPI should include in the "product / component description" indication of one of: REVIEW DRAFT - 1. CAPI 1.0 for POWER8 Adapters on PCIe Gen3 or 2. CAPI 2.0 for POWER9 Adapters on PCIe Gen4.

Figure 5.1. OpenPOWER CAPI Solution REVIEW DRAFT -

REVIEW DRAFT - CAPI solutions include an adapter and its associated driver and management software, and one or more Accelerator Functional Units (AFUs) and libraries or applications that access them. An adapter may support multiple separately sold or user developed AFUs, or it may be packaged with a fixed set of AFUs as a dedicated solution. To be OpenPOWER Ready, a CAPI capable product must meet the following criteria:

1. The product must be supported on at least one OpenPOWER Ready system.

2. Hardware and software components must meet the criteria for adapters and applications listed below. If a solution includes both adapter hardware and application/AFU components, each must meet the relevant criteria. REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation 12 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

5.1. OpenPOWER Ready Criteria for CAPI Adapters 5.1.1. CAPI 1.0 for POWER8 Adapters on PCIe Gen3

CAPI capable PCIe adapters must meet the criteria for OpenPOWER Ready I/O Adapters, as specified in Chapter 4, “OpenPOWER Ready I/O Adapter” [9] above. In addition, CAPI adapters

REVIEW DRAFT - must support the following CAPI specific criteria:

1. Accelerated Functional Units (AFUs) must communicate with the IBM licensed Power Service Layer (PSL) using the PSL/AFU Interface. The PSL / AFU Interface Specification found here: https://openpowerfoundation.org/?resource_lib=psl-afu-interface-specification.

The PSL Simulation Engine (PSLSE) or equivalent method may be used to verify that the AFU correctly implements the PSL/AFU Interface. The PSLSE is available via GITHUB at https:// github.com/ibm-capi/pslse.

2. Applications and/or interface libraries running on the OpenPOWER host should use an API library which satisfies the CAIA 1.0 to control and communicate with supporting AFUs. The Coherent Accelerator Interface Architecture (CAIA) Specification found here: https://

REVIEW DRAFT - openpowerfoundation.org/?resource_lib=coherent-accelerator-interface-architecture-caia-specification

3. For reference information see the OpenPOWER CAPI 1.0 Accelerator Compliance: Test Specifi- cation. It can be found here: https://openpowerfoundation.org/?resource_lib=openpower-capi- accelerator-compliance-test-specification

Note

The open source CAPI library libcxl https://github.com/ibm-capi/libcxl. may be used and assumed compliant with CAIA.

REVIEW DRAFT - 5.1.2. CAPI 2.0 for POWER9 Adapters on PCIe Gen4

1. Accelerated Functional Units (AFUs) must communicate with the IBM licensed Power Service Layer (PSL) using the PSL/AFU Interface. The PSL / AFU Interface: CAPI 2.0 Specification can be found here: https://openpowerfoundation.org/?resource_lib=psl-afu-interface-capi-2-0

2. Applications and/or interface libraries running on the OpenPOWER host should use an API library which satisfies the CAIA to control and communicate with supporting AFUs. The Coherent Accelerator Interface Architecture (CAIA) Version 2 Specification found here: https://

Workgroup Specification OpenPOWER Foundation 13 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

openpowerfoundation.org/?resource_lib=coherent-accelerator-interface-architecture-version-2- caia2-specification

3. For reference information see the OpenPOWER CAPI 2.0 Accelerator Compliance: Test Specifi- cation. It can be found here: https://openpowerfoundation.org/?resource_lib=openpower- capi-2-0-accelerator-compliance-test-specification Note

The open source CAPI library libcxl https://github.com/ibm-capi/libcxl. may be used

REVIEW DRAFT - and assumed compliant with CAIA. 5.2. OpenPOWER Ready Criteria for CAPI Applications 5.2.1. CAPI 1.0 Applications

The application code running on an OpenPOWER Ready operating system on an OpenPOWER Ready system is uniquely tied to Accelerated Functional Units (AFUs) that implement the accelerated services it requires. OpenPOWER Ready applications and/or AFUs must meet the following criteria: REVIEW DRAFT - 1. Use of an OpenPOWER Ready CAPI adapter per Section 5.1.1, “CAPI 1.0 for POWER8 Adapters on PCIe Gen3” [13].

2. Accelerated Functional Units (AFUs) must communicate with the IBM licensed Power Service Layer (PSL) using the PSL/AFU Interface.

3. Applications and/or interface libraries running on the OpenPOWER host should use an API library which satisfies the CAIA to control and communicate with supporting AFUs. REVIEW DRAFT - Note

The open source CAPI library libcxl may be used and assumed compliant with CAIA. 5.2.2. CAPI 2.0 Applications

1. Use of an OpenPOWER Ready CAPI 2.0 adapter per Section 5.1.2, “CAPI 2.0 for POWER9 REVIEW DRAFT - Adapters on PCIe Gen4” [13].

2. Accelerated Functional Units (AFUs) must communicate with the IBM licensed Power Service Layer for POWER9 (PSL9) using the PSL/AFU Interface CAPI 2.0. The PSL Simulation Engine

Workgroup Specification OpenPOWER Foundation 14 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

for CAPI 2.0 (PSLSE 2.0) or equivalent method may be used to verify that the AFU correctly implements the PSL/AFU Interface. The PSLSE is available via GITHUB at https://github.com/ ibm-capi/pslse (capi2 branch).

3. Applications and/or interface libraries running on the OpenPOWER host should use an API library which satisfies the CAIA 2.0 to control and communicate with supporting AFUs.

4. The CAPI application provider must run a provided application exerciser for their AFU/application with a system exerciser that satisfies the criteria in Section 2.2, “ISA Profile rev 2.0.0 based systems” [5] (bullet #5 [6]). REVIEW DRAFT - Note

The open source CAPI library libcxl may be used and assumed compliant with CAIA 2.0. REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation 15 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

6. OpenPOWER Ready CAPI SNAP

The CAPI SNAP Framework enables programmers and computer engineers to quickly create FPGA- based acceleration actions utilizing CAPI. It consists of software running on OpenPOWER systems, and FPGA hardware logic implemented on an I/O adapter card. The SNAP software and hardware is published as open-source on https://github.com/open-power/snap.

Figure 6.1, “CAPI SNAP Components ” [16] shows the hardware and software components that

REVIEW DRAFT - SNAP provides in orange. Underlying CAPI components are marked in green, and the user written parts in yellow.

Figure 6.1. CAPI SNAP Components REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT -

The base CAPI components are covered by Chapter 5, “OpenPOWER Ready CAPI” [12].

Workgroup Specification OpenPOWER Foundation 16 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

CAPI SNAP solutions product must meet the following criteria:

1. The product must be supported on at least one OpenPOWER Ready system.

2. Hardware and software components must meet the criteria for adapters and applications listed in Section 6.1.1, “FPGA Logic” [17] or Section 6.1.2, “Applications” [17] below. 6.1. OpenPOWER Ready Criteria for CAPI

REVIEW DRAFT - SNAP Solutions 6.1.1. FPGA Logic CAPI SNAP is based on CAPI, using only IBM licensed Power Service Layers optimized for SNAP. The software library libsnap depends on the libcxl which is assumed compliant with CAIA. SNAP therefore makes sure all adapters satisfy the CAPI criteria listed in Section 5.1, “OpenPOWER Ready Criteria for CAPI Adapters” [13], The I/O adapter must still meet the criteria for OpenPOWER Ready I/O Adapters, as specified in Chapter 4, “OpenPOWER Ready I/O Adapter” [9] above.

The OpenPOWER Ready CAPI SNAP FPGA logic images must meet the following criteria:

1. The FPGA logic loaded onto the Adapter card must be built from a released version of the CAPI

REVIEW DRAFT - SNAP github project on https://github.com/open-power/snap using the IBM provided PSL for POWER, the supported build setup (make), Xilinx FPGA tools and configurations.

2. The action must implement the required action interface ports and registers as described in the SNAP documentation on github. 6.1.2. Applications CAPI SNAP applications communicate with the hardware action using the libsnap software library. This library uses the libcxl to access the CAPI SNAP hardware device. Libcxl is assumed compliant with CAIA, so all applications that use the SNAP library functions exclusively to communicate with the adapter do meet the criteria defined in Section 5.1, “OpenPOWER Ready Criteria for CAPI Adapters” [13] already. REVIEW DRAFT - The application code running on an OpenPOWER Ready operating system on an OpenPOWER Ready system is uniquely tied to the action user logic implemented on the I/O adapter card.

The OpenPOWER Ready CAPI SNAP applications must meet the following criteria:

1. Applications and/or interface libraries running on the OpenPOWER host must use the software library provided by the CAPI SNAP github project on https://github.com/open-power/snap.

2. The CAPI SNAP application provider must run a provided application exerciser for their application with a system exerciser that satisfies the criteria in Section 2.1, “ISA Profile rev 1.0.0 based systems” [4] (bullet 5) or in Section 2.2, “ISA Profile rev 2.0.0 based systems” [5] (bullet 5). Note REVIEW DRAFT - The open source CAPI library libcxl may be used and assumed compliant with CAIA. The CAPI SNAP software library libsnap calls libcxl for all communication with the I/ O adapter, so it may be used and assumed compliant with CAIA, too.

Workgroup Specification OpenPOWER Foundation 17 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

7. OpenPOWER Ready OpenCAPI™ 3.0

The OpenPower Ready mark also applies to OpenCAPI 3.0 adapters and the solutions built using them. The following graphic Figure 7.1, “OpenPOWER OpenCAPI 3.0 Solution ” [18] provides an abstracted view of a notional OpenPOWER OpenCAPI 3.0 solution and its key components.

Figure 7.1. OpenPOWER OpenCAPI 3.0 Solution REVIEW DRAFT - REVIEW DRAFT -

OpenCAPI 3.0 solutions may include an optional adapter but are required to have an associated driver and management software, and one or more Accelerator Functional Units (AFUs) and libraries or applications that access them.

REVIEW DRAFT - OpenCAPI 3.0 products must meet the following requirements:

1. The product must be supported on at least one OpenPOWER Ready system.

2. Hardware and software components must meet the criteria for adapters and applications as listed below. 7.1. OpenPOWER Ready Criteria for OpenCAPI 3.0 Adapters 7.1.1. OpenCAPI 3.0 Adapters for POWER9 REVIEW DRAFT -

1. OpenCAPI 3.0 capable adapters must support an OpenCAPI 3.0 DLx and an optional TLx as defined by the TL 3.0 and DL 3.0 Architectural Specifications as published on the opencapi.org website http://opencapi.org.

Workgroup Specification OpenPOWER Foundation 18 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

2. The adapter should support a kernel and application API library which satisfies the OpenCAPI Architecture Note The OpenCAPI 3.0 library libocxl may be used and assumed compliant from the OpenCAPI Enablement Workgroup under the OpenCAPI consortium.

3. The OpenCAPI 3.0 PHY interconnect should refer to the Advanced Accelerator Adapter Electro-Mechanical Specification that is published on the OpenPower Website. https://

REVIEW DRAFT - openpowerfoundation.org/?resource_lib=advanced-accelerator-adapter-electro-mechanical-specification.

4. Accelerated Functional Units (AFUs) must communicate with the OpenCAPI 3.0 DLx/TLx thru a TLx/AFU Interface. The TLx/AFU interface specification from the OpenCAPI Enablement Workgroup under the OpenCAPI Consortium may be used. The OpenCAPI 3.0 Simulation Engine (OCSE) or equivalent method may be used to verify that the AFU correctly implements the TLx/AFU inferface. The OCSE may be obtained from the OpenCAPI Enablement Workgroup under the OpenCAPI Consortium

5. Applications and/or interface libraries running on the OpenPower host should use an API library which satisfies the OpenCAPI POWER Platform Architecture (OPPA) for control and communication to the AFUs REVIEW DRAFT - Note The OpenCAPI 3.0 library libocxl may be used and assumed compliant with the OpenCAPI 3.0 OPPA. 7.2. OpenCAPI 3.0 Applications The application code running on an OpenPOWER Ready operating system on an OpenPOWER Ready system is uniquely tied to Accelerated Functional Units (AFUs) that implement the accelerated service it requires. OpenPOWER OpenCAPI 3.0 Ready applications and/or AFUs must meet the following criteria:

REVIEW DRAFT - 1. Use of an OpenPOWER Ready OpenCAPI 3.0 adapter per Section 7.1.1, “OpenCAPI 3.0 Adapters for POWER9” [18].

2. Accelerated Functional Units (AFUs) must communicate with the OpenCAPI 3.0 TLx using the OpenCAPI 3.0 TLx/AFU interface. The OpenCAPI 3.0 Simulation Engine or equivalent method may be used to verify that the AFU correctly implements the OpenCAPI 3.0 TLx/AFU Interface. The OCSE is available from the OpenCAPI Enablement Workgroup under the OpenCAPI Consortium

3. Applications and/or interface libraries running on the OpenPower host should use an API library which satisfies the OpenCAPI POWER Platform Architecture (OPPA) for control and communication to the AFUs

REVIEW DRAFT - Note The OpenCAPI 3.0 library libocxl may be used and assumed compliant with the OpenCAPI 3.0 OPPA.

Workgroup Specification OpenPOWER Foundation 19 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

8. OpenPOWER Ready System Support Components

System support components are components or products that are integral to the system design but are not integral in the architecture computationally. OpenPOWER Ready for such components or products implies that the developer is asserting these components or products may be considered for inclusion in system designs intended for the OpenPOWER community. The OpenPOWER Ready

REVIEW DRAFT - Marking does not indicate such components may be incorporated without proper design, validation, and qualification per accepted design practice.

The System Support Components category is broad and within it are potentially several sub- categories. Future versions of this document may refine the definition, sub-categories, and appropriate criteria.

To be OpenPOWER Ready, a System Support Component should meet one of the following criteria:

1. The component or product should be incorporated in at least one OpenPOWER Ready system.

2. The component / product developer asserts the component / product has been tested and may be considered for use. REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation 20 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

Appendix A. OpenPOWER Foundation overview

The OpenPOWER Foundation was founded in 2013 as an open technical membership organization that will enable data centers to rethink their approach to technology. Member companies are enabled to customize POWER CPU processors and system platforms for optimization and innova- tion for their business needs. These innovations include custom systems for large or warehouse

REVIEW DRAFT - scale data centers, workload acceleration through GPU, FPGA or advanced I/O, platform optimization for SW appliances, or advanced hardware technology exploitation. OpenPOWER members are actively pursing all of these innovations and more and welcome all parties to join in moving the state of the art of OpenPOWER systems design forward.

To learn more about the OpenPOWER Foundation, visit the organization website at openpowerfoundation.org. A.1. Foundation documentation

Key foundation documents include:

REVIEW DRAFT - • Bylaws of OpenPOWER Foundation

• OpenPOWER Foundation Intellectual Property Rights (IPR) Policy

• OpenPOWER Foundation Membership Agreement

• OpenPOWER Anti-Trust Guidelines

More information about the foundation governance can be found at openpowerfoundation.org/about- us/governance. A.2. Technical resources REVIEW DRAFT -

Development resouces fall into the following general categories:

• Foundation work groups

• Remote development environments (VMs)

• Development systems

• Technical specifications

• Software REVIEW DRAFT - • Developer tools

The complete list of technical resources are maintained on the foundation Technical Resources web page.

Workgroup Specification OpenPOWER Foundation 21 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - OpenPOWER Ready™ November 13, 2017 Revision 2.0 - PRD

A.3. Contact the foundation

To learn more about the OpenPOWER Foundation, please use the following contact points:

• General information --

• Membership --

• Technical Work Groups and projects -- REVIEW DRAFT - • Events and other activities --

• Press/Analysts --

More contact information can be found at openpowerfoundation.org/get-involved/contact-us. REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT -

Workgroup Specification OpenPOWER Foundation 22 Standard Track REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT - REVIEW DRAFT -