The Capability Registers specify read-only limits, restrictions and capabilities of the host controller implementation. These values are used as parameters to the host controller driver.
Capability Registersには、そのホストコントローラーが備える機能や制限、上限などの読み取り専用の情報が規定されています。それらの値はホストコントローラードライバーのパラメータに使われます。
The USB Base Address Register (BAR) in the PCI Config Space points to the base address of the xHC register interface. The xHC register interface consists of 4 major components: Capability Registers, Operational Registers, Runtime Registers, and the Doorbell Array. The Operational and Capability Regist ers are concatenated in MMIO space. The Runtime Registers are actually just an extension of the Operational Registers. Their partitioning allows the xHC to better support virtualization, by allowing the Runtime Registers to reside on a separate page boundary. A xHCI Capabilities Pointer mechanism (similar to that defined by PCI) is presented in the Capability Registers to point to new or optional capabilities of an xHC implementation.
PCIコンフィギュレーション空間のUSBBARはXHCレジスタインターフェースのベースアドレスを指し示します。xHCレジスタインターフェースはCapability レジスタ, Operational レジスタ, Runtime レジスタ、 Doorbell Arrayの4つの主要な要素で構成されます。Capability レジスタ, Operational レジスタはMMIO空間に連結されています。Runtimeレジスタは実はOperational レジスタの延長です。これらのレジスタを分割することで、Runtime Registersを別のページ境界に配置できるようになり、xHCは仮想化をより適切にサポートできます。PCIで定義されている仕組みに似たxHCI Capabilities Pointerという仕組みがCapability Registers内に用意されており、xHCの実装が持つ新しい機能やオプション機能を指し示します。
The xHCI provides support for two categories of USB transfer types: asynchronous and periodic. Isochronous and Interrupt transfers are Periodic transfer types. Asynchronous transfer types include Control and Bulk. Figure 3-3 illustrates that the xHCI provides a homogeneous mechanism (Transfer Rings) for each category of transfer type.
xhciは非同期と定期の2種類のカテゴリのUSB転送タイプに対応しています。アイソクロナス転送と割り込み転送は定期転送タイプです。非同期転送にはControlとBulkがあり、xHCIではそれぞれを扱うために共通のTransfer Ringという仕組みを使用している。
This space is defined by the control data structures (Device Context Base Address Array, Device Contexts, Transfer Rings, etc.) and data buffers that are allocated and managed by the xHC Driver to enable the endpoint traffic of individual devices. This sp ace is allocated in the Kernel and User areas of the Memory Address Space.
このスペースはコントロールデータストラクチャと個人デバイスのエンドポイントの通信の往来を可能にするためのxHCドライバーによって割当、管理するデータバッファによって定義されます。このスペースはメモリアドレス空間のユーザーエリアとカーネルに割り当てられます。
The Register Space represents the hardware registers presented by the xHC to system software that reside in the Memory Address Space. The Register Space provides for the implementation - specific parameters defined in the xHCI normal and Extended Capabilities registers, the Operational and Runtime control and status registers, and the Doorbell Array used to flag accesses to individual USB devices. This space, normally referred to as I/O space, is implemen ted as Memory-Mapped I/O (MMIO) space.
レジスタスペースはメモリアドレススペースにいるxHCからシステムソフトウェア用のハードウェアレジズタスペースを表します。レジスタスペースは個人デバイスのフラグへアクセスするのに使うxhciの標準、拡張Capabilitiesレジスタ,Operational、Runtime control、 status レジスタ、 Doorbell Arrayで特定の機能のパラメータを定義します。このスペースは通称I/Oスペースと呼ばれ、MMIO空間として実装されます。
Every xHC implementation shall include a means of identifying and enumerating the host controller by system software. This specification provides a PCI example of the Host Configuration Space, which is referred to as PCI Config Space. The PCI Config Space definition provides a working example of configuration space use for system xHC enumeration and resource (interrupt, power, virtualization, etc.) management.
全てのxhcの実装は識別子とシステムソフトウェアによって列挙されたホストコントローラーを含みます。この仕様はホストコンフィギュレーション空間の例であるPCIコンフィギュレーション空間を実現します。PCI Config Spaceの定義では、システムによるxHCの列挙・認識や、リソース（割り込み、電力、仮想化など）の管理のためにConfiguration Spaceを使用する具体例が示されています。
The xHCI interface defines three interface spaces (refer to Figure 3-3):
xhciインターフェースは三つのインターフェーススペースで定義されます。（図3-3参照）
The xHC always manages the respective speed USB devices connected to its Root Hub ports. Depending on the implementation, the resources of a USB bus instance (bandwidth, device addressability, etc.) may be presented on each root hub port, shared across multiple root hub ports, or a combination of allocations. This specification defines the registers and interfaces for the eXtensible Host Controller Interface.
xhcは常にルートハブポートに接続されたそれぞれのUSBデバイスの通信速度を管理します。USBバスインスタンスのリソースは複数のルートハブポートで共有、あるいは割り当ての組み合わせの各ルートハブポートに提供されるでしょう。
この仕様はxhciのレジスタ群とインターフェースを定義します。
Note that Figure 3-2 does not imply a particular xHC implementation, however the functional partitioning that it illustrates is useful for this discussion. The Host Interface Logic manages the Registers and DMA associated with the xHC.
図3-2は特定のxhcの実装を暗示していないことに注意してください、しかしこの議論において図示された機能分割は役に立ちます。ホストインターフェースロジックはレジスタ群とxhcに関連したDMAを管理します。
The xHCI architecture allows the USB3 host controller to provide USB functionality for all speed devices without requiring, as in previous generations, companion controllers along with the associated software support for their respective drivers. The enhanced features of the xHCI architecture are key to delivering this simplified operating environment.
xHCIアーキテクチャでは、USB 3ホストコントローラーだけで、さまざまな速度のUSBデバイスにUSB機能を提供できます。従来の世代のように、Companion Controllerや、それぞれのドライバをサポートするための関連ソフトウェアを必要としません。 xHCIアーキテクチャの強化された機能が、この簡素化された動作環境を実現するための鍵となっています。
The xHCI is used for all communications to devices connected through the Root Hub ports of the USB3 host controller.
xhciはUSB3ホストコントローラーのルートハブを通じてデバイスを繋げるための全ての通信を使用します。
Native OS support for Device Classes allows a compliant device to provide a user with basic functionality if the vendor Device Class drivers are not available, however a vendor can define their own Class Driver to add value. Many commodity USB device vendors (mice, keyboard, etc.) take advantage of those provided by OS vendors and don’t bother to offer their own Class Drivers. If a vendor offers a USB device that does not fall under one of the standard USB defined Device Classes supported by an OS then they shall offer their own Class Driver.
OSがDevice Classを標準でサポートしていれば、仕様に準拠したデバイスは、メーカー独自のDevice Class Driverが利用できない場合でも、ユーザーに基本的な機能を提供できます。ただし、メーカーは独自のClass Driverを定義して付加価値を加えることもできます。多くの一般的なUSB機器メーカー（マウス、キーボードなど）は、OSベンダーが提供するClass Driverを利用しており、自社独自のClass Driverをわざわざ提供していません。もしメーカーが、OSによってサポートされている標準USB Device Classのいずれにも該当しないUSBデバイスを提供する場合、そのメーカーは独自のClass Driverを提供しなければなりません。
Working groups in the USB-IF have defined several standard USB Device Classes (Mass Storage, Audio, etc.). A USB device vendor may choose to define a proprietary Device Class for their product or utilize part or all of an appropriate USB-IF defined Device Class. The USB-IF defined Device Classes provide a baseline set of features, for their respective class. Several USB Device Classes are supported natively by today’s Operating Systems.
USB-IFはいくつかの標準USBデバイスクラスを定義しました。ベンダーは商品もしくは部品の活用もしくはUSB-IFのデバイスクラスすべてのために独自のデバイスクラスを定義します。USB-IFが定義したデバイスクラスはそれぞれのクラス用の基礎機能のセットを提供します。現在のOSでいくつかのUSBデバイスクラスは標準で対応しています。
“value add” that a vendor may provide. As long as the USB Framework presented through the USBDI remains unchanged, the USB Class Drivers do not have to change because the USB bus driver does (e.g. to support the xHCI)
Class Driverには、ベンダーが独自に提供する付加価値も含まれます。USBDIを通して提供されるUSB Frameworkが変更されない限り、USB Bus Driverが変更されたとしても（例えばxHCIをサポートするために）、USB Class Driverを変更する必要はありません。
The USB bus driver (USBD) provides a standard method of interfacing to the transport mechanisms (USB Framework) defined by the USB architecture (Isoch, Interrupt, Control, and Bulk Pipes) and the Device Class driver is where all the application specific knowledge resides.
USB Bus Driver（USBD）は、USBアーキテクチャによって定義された転送メカニズム（USB Framework：Isoch、Interrupt、Control、Bulk Pipe）とやり取りするための標準的な方法を提供します。一方、アプリケーション固有の知識はすべてDevice Class Driverに存在します。
The Device Framework allows the USB architecture to separate the details of the “Bus” interface from that of the application specific (“Device”) interface, resulting in a split driver model (xHCD/Class Driver). Note that in this context, Device Class refers to the portion of a USB device that performs some useful end user application specific function (e.g. Mass Storage, Audio, Human Interface, etc.).
デバイスフレームワークはアプリケーションのデバイスインターフェースからバスインターフェースの詳細を分離させることをUSBアーキテクチャに許可します、その結果分割型ドライバーモデルになります。ここでいうDevice Classとは、USBデバイスの中で、ストレージやオーディオ、キーボードなど、エンドユーザーが利用する特定の機能を担当する部分を指します。
A key feature of the USB architecture is the Device Framework that it presents. The Device Framework defines the interface between a USB device and a Class Driver, which is independent of the particular host controller interface that a system employs to communicate with the USB. This interface consists of a Default Pipe, and zero or more additional class defined Pipes. The Default Pipe (also referred to as the Default Control Endpoint) is used to enumerate and manage a USB device. It can also be used to provide access to application specific features of the device. The class defined Pipes provide specialized Quality-of-Service requirements to perform device class specific functions.
USBアーキテクチャの主な特徴はデバイスフレームワークが提供します。デバイスフレームワークはUSBデバイスとクラスドライバー間のインターフェースを定義し、それはシステムがUSBと通信するために使われ特定のホストコントローラーインターフェースから独立しています。このインターフェースはデフォルトパイプとクラス定義された0個以上の追加パイプで構成されます。そのデフォルトパイプ（おそらくデフォルトコントロールパイプと呼ばれる）はUSBデバイスの列挙と管理に使用されます。それはデバイスのアプリの特定の機能へのアクセスを提供するのにも使われます。クラス定義されたパイプはデバイスクラスの特定の機能を実行する特化したサービス品質要件を提供します。
This is a hardware device that expands the bus topology (hub) or performs a useful end-user function. Interactions with USB devices flow from the applications through the software and hardware layers to the USB devices.
これは、USBハブのようにバストポロジーを拡張したり、キーボードなどのようにエンドユーザー向けの機能を提供したりするハードウェアデバイスです。USBデバイスとの通信は、アプリケーションからソフトウェア層、ハードウェア層を経由してUSBデバイスへと伝わります。
The host controller is the specific hardware implementation of the host controller architecture. There is one host controller specification for the USB3 host controller, which enables support for Low-, Full-, High-, SuperSpeed, and SuperSpeedPlus devices. The interface presented by the xHC to the system is referred to as the eXtensible Host Controller Interface or the xHCI.
xhcはホストコントローラーアーキテクチャの特定のハードウェア実装です。USB3ホストコントローラーのためのホストコントローラーの仕様が一つあり、Low-, Full-, High-, SuperSpeed, and SuperSpeedPlusデバイスに対応しています。xHCがシステムに提供するインターフェースは、eXtensible Host Controller Interface、またはxHCIと呼ばれます。
xHCD provides the software layer between the Host Controller hardware and the USBD. The details of the host controller driver depend on the host controller hardware register interface definition.
xHCDホストコントローラーハードウェアとUSBDの間のソフトウェアレイヤーによって実現されます。ホストコントローラードライバーの詳細はホストコントローラーハードウェアレジスタインターフェースの定義によって決まります。
The USBD is a system software Bus Driver that abstracts the details of the particular Host Controller Driver for a particular operating system. The generic USB interface p resented to the system by USBD is referred to as the USB Driver Interface or the USBDI.
USBDは特定のOSのための特定のホストコントローラードライバーの詳細を抽象化するバスドライバーです。汎用USBインターフェースはUSBDIかUSBドライバーインターフェースと呼ばれているUSBDによって提示されます。
This software executes on the host PC corresponding to a particular “class” of USB device (Mass Storage, Human Interface, Audio, etc.). Class Driver software is typically part of the operating system or provided with the USB device.
このソフトウェアはUSBデバイスの特定の「クラス」に対応するホストPCで処理される。クラスドライバはosの一部であるかUSBデバイスを用いて実現されます。
This software uses the services provided by one or more USB devices. Application software interfaces with USB devices through standardized interfaces provided by the Class Drivers.
このソフトウェアは一つ以上のUSBデバイスによって実現されたサービスです。 アプリケーションソフトウェアインターフェースはクラスドライバによって標準化されたインターフェースを介してUSBデバイスを用います。
A USB Host System is composed of a number of hardware and software layers. Figure 3-1 illustrates a conceptual block diagram of the building block layers in a host system that work in concert to support USB 3.x.
USBホストシステムはいくつかのハードウェアとソフトウェアレイヤーで構成されています。 図3-1はUSB3.xに対応するための連携するホストシステムの構成単位の概念ブロック図を図示します。
Adopters and Contributors of the eXtensible Host Controller Interface Specification for Universal Serial Bus (xHCI) have signed the eXtensible Host Controller Interface (xHCI) Specification Contributor Agreement in order to be licensed to use and implement this Specification. This Contributors Agreement provides Contributors and Adopters with a reciprocal, royalty-free license to certain intellectual property rights from Intel and other Adopters and Contributors for their products that are compliant with the xHCI specification. Adopters and Contributors can demonstrate compliance with the Specification through the testing program as defined by Intel.
xHCI仕様を使いたい ↓ Contributor Agreementに署名する ↓ 仕様を使用・実装するライセンスを得る ↓ 一定の知的財産権について 相互・ロイヤリティなしのライセンスが得られる ↓ Intelのテストプログラムで xHCI仕様への準拠を証明できる
Through use of the PCIe SR-IOV specification, the xHCI provides a Virtual Machine Manager with the ability to enable Virtual xHCs
PCIe SR-IOV仕様を使う中でxhciは(VxHCs)コントローラーを有効にする機能を仮想マシンマネージャーに提供していくつかのUSB デバイスをVxHCインターフェースに割り当てます。 仮想化機能はxhciの任意規格です。
Support for Virtual Memory. All xHCI register and data structures are designed to support the “coarse-grain” Scatter/Gather requirements of page based virtual memory architectures. Support for “fine-grain” Scatter/Gather. The interface supports a hardware scatter/gather method for all data transfers that may be used for accessing memory. The EHCI scatter/gather mechanism was an example of Coarse Grain scatter/gather. It was tailored specifically to work with page based virtual memory, specifying a Start Offset, a Transfer Length and a list of Page aligned addresses. The xHCI scatter/gather mechanism is not constrained by memory page boundary or size limitations. xHCI scatter/gather lists may be comprised of buffers starting on any byte boundary and any byte length. This feature allows the xHCI scatter/gather mechanism to be used for accessing page aligned data, as well as at the application level to minimize software data copies.
仮想メモリのサポート xHCIのすべてのレジスタおよびデータ構造は、ページベースの仮想メモリアーキテクチャにおける「粗い粒度（coarse-grain）」のScatter/Gather要件をサポートするように設計されています。
「細かい粒度（fine-grain）」のScatter/Gatherのサポート このインターフェースは、メモリへのアクセスに使用される可能性のあるすべてのデータ転送について、ハードウェアによるScatter/Gather方式をサポートしています。EHCIのScatter/Gather機構はCoarse Grain Scatter/Gatherの一例でした。これはページベースの仮想メモリで動作することに特化されており、開始オフセット、転送長、およびページ境界に揃えられたアドレスのリストを指定していました。一方、xHCIのScatter/Gather機構は、メモリのページ境界やサイズによる制限を受けません。xHCIのScatter/Gatherリストは、任意のバイト境界から開始し、任意のバイト長を持つバッファから構成できます。この機能により、xHCIのScatter/Gather機構はページ境界に揃えられたデータへのアクセスだけでなく、アプリケーションレベルでソフトウェアによるデータコピーを最小限にするためにも使用できます。
Over the implementation lifetime of this specification, it is expected that xHCI controllers will be used increasingly in architectures that support more than 32-bits of addressable memory space. The xHCI inherently supports up to 64-bits of addressing.
本仕様に実装期間にわたりxhciは32bitアドレス空間での使用を想定していますが本質的には64bitに対応しています。
The xHCI provides a simple interface for software to provide the host controller with parameterized Transfer Requests that the host controller uses to execute transactions on the USB. The interface allows software to asynchronously add work to the interface while the host controller is executing, without requiring the use of software synchronization primitives.
xHCIは、ソフトウェアがホストコントローラーにパラメータ化されたTransfer Requestを渡すための、シンプルなインターフェースを提供する。 インターフェースは使用しているソフトウェアの同期プリミティブの許可なしでホストコントローラー処理中に非同期にインターフェースに作業の追加を許可します。
The xHCI’s data transfer model eliminates the memory based transaction schedules that existed in previous host controller architectures. It utilizes Transfer level operations to decrease the average number of memory accesses required to execute USB operations.
xhciのデータ転送モデルは前のホストコントローラーアーキテクチャに存在したメモリに置かれたトランザクションスケジュールを削除します。それはUSB命令処理を要求するメモリアクセスの平均回数を減らすために転送レベルの命令で活用されます。
The xHCI specification enables solutions to a myriad of issues, which have proven to be problematic for USB host controllers. Some of the issues resolved in the xHCI specification include: Memory thrashing, Memory access efficiency, and conflicts with CPU power management. The xHCI architecture provides both new specific features and optimizations to its architecture to solve the legacy issues.
xhci仕様書はUSBホストコントローラーで判明した無数の問題を解決してくれます。メモリスラッシング、効率的なメモリアクセスCPU電力管理の衝突といったいくつかの問題をxhci仕様書は解決しました。xhciアーキテクチャは新しい特有の機能と従来の問題を解決するための最適化されたアーキテクチャを実現しました。
51 by the xHCI. Special attention has been paid to minimizing power consumption when the system is Idle. USB is a critical component in delivering a consistent, coherent and robust user experience. If the implementation includes PCI configuration registers, then the host controller is required to implement a PCI Power Management Interface (PCI PM).
USB2LPM拡張機能はxhciに対応しています。特に注目されているのがシステムが停止状態の時電力消費を最小化することです。USBの重要なコンポーネントは一貫性と堅牢なユーザーエクスペリエンスで一貫して提供され続けています。機能にPCIコンフィギュレーションレジスタが含まれるときホストコントローラーはPCI電力管理インターフェース機能を必要とします。
System Power Management. Current PC architectures are providing ubiquitous support for aggressive power management. The USB3 architecture focuses on power conservation to improve battery life in mobile, battery powered applications. USB2 LPM (Link Power Management) extensions are also supported
現在のPCアーキテクチャは積極的な電力管理のためのユビキタスを実現している。USB 3アーキテクチャは、モバイル機器などのバッテリー駆動環境でバッテリー寿命を延ばすため、省電力化を重視しています。
Support for all USB device speeds. The xHCI specification defines support for all USB device speeds including; USB 2.0 Low-, Full-, and High-speed devices, and USB 1.1 Low- and Full-speed.
xhci仕様書はすべてのUSBデバイスの速度を網羅している。一覧：USB 2.0 Low-, Full-, and High-speed devices,and USB 1.1 Low- and Full-speed.
Robust Support for all USB 3.x Features. This specification describes a host controller architecture that is capable of supporting compliant USB 3.x SuperSpeedPlus and SuperSpeed devices. This includes new USB 3.x features such as asynchronous transactions and other extensions to the protocol.
この仕様書は、USB 3.xの仕様に準拠したSuperSpeedPlusおよびSuperSpeedデバイスをサポートできるホストコントローラーアーキテクチャについて説明しています。
名詞 + that + 動詞 ... 「thatの前の名詞について追加説明している」
Efficient operation – idle power and performance better than current USB host controller architectures. A device level programming model that is fully consistent with the existing USB software model Decouple the host controller interface presented to software from the underlying USB protocols Minimize host memory accesses, fully eliminating them when USB devices are idle Eliminate the “Companion Controller” model Enable hardware “fail-over” modes in system resource constrained situations so devices are still accessible, but perhaps at less optimal power/performance point Provide the ability for different markets to differentiate hardware capabilities, e.g. target host controller power, performance and cost trade-offs for specific markets Define an extensible architecture that provides an easy path for new USB specifications and technologies, such as higher bandwidth interfaces, optical transmission medium, etc., without requiring the definition of yet another USB host controller interface
・効率的な操作-停止状態の電力と性能が現在のUSBホストコントローラーより良い ・デバイスレベルのプログラミングモデルが既存のUSBソフトウェアモデルと完全に整合性がとれている ・ソフトウェアに提示されるホストコントローラーインターフェースを、その下にあるUSBプロトコルから切り離す ・ホストメモリアクセスが最小化されて、USBデバイスたちが停止状態の時完全に排除されている ・"Companion Controller”モデルを排除する ・ある機能・装置が使えなくなったとき、最適な電力消費や性能でなくても別の方法に切り替えて動作を継続する。 ・市場ごとに、ホストコントローラーの消費電力・性能・コストのバランスを変えられるようにする ・将来、新しいUSB技術が新しくUSBホストコントローラーインターフェースを定義する必要なし対応しやすいアーキテクチャにする
The goal of xHCI architecture is to define a USB host controller to ultimately replace UHCI/OHCI/EHCI, to provide highly power efficient operation, higher performance, and extensibility to new USB specification s, such as USB3 and beyond. Key xHCI architectural goals are:
xhciの目的はUSBホストコントローラーが最終的にUHCI/OHCI/EHCIの代わりになることでUSB3やそれ以上の効率的な命令と高パフォーマンスとUSB仕様の拡張性を実現することです。キーとなるxhciアーキテクチャのゴールは
The eXtensible Host Controller Interface addresses these factors. In addition, the xHCI architecture provides a new industry standard means for interfacing to USB devices that delivers the extensibility necessary to meet future needs.
xhciのアドレスはこれらの要因で構成されています。加えてxhciアーキテクチャは将来の需要を満たすのに必要な拡張性をもたらす新しい工業的な標準基準を実現します。
Virtualization is beginning to play a key role in system architectures and the legacy USB host controller architectures exhibit some serious shortcomings when applied to virtualized environments. Legacy USB host controller interfaces define a data pump; where critical state related to overall bus management (Bandwidth allocation, Address assignment, etc.) reside in the software driver. Trying to apply the standard hardware IO virtualization technique, of replicating IO interface registers, to the legacy USB host controller interface is problematic because critical state that must be managed across Virtual Machines (VMs) is not available to hardware. The xHCI architecture moves the control of this critical state into hardware, enabling USB resource management across VMs. The xHCI virtualization features also provide for: 1) Direct-Assignment of individual USB devices (irrespective of their location in the bus topology) to any VM, 2) minimizing run-time inter-VM communications, and 3) support for native USB device sharing.
仮想化はシステムアーキテクチャにおいて重要な役割を果たし始めています。しかし、従来のUSBホストコントローラーのアーキテクチャには、仮想化環境で使用する際に重大な問題があります。従来のUSBホストコントローラーでは、USBバス全体の管理に関係する重要な状態情報（帯域幅の割り当てやアドレスの割り当てなど）がソフトウェアドライバ側に存在します。そのため、I/Oインターフェースのレジスタを複製するという一般的なI/O仮想化技術を従来のUSBホストコントローラーに適用することは困難です。これは、複数のVMにまたがって管理する必要がある重要な状態情報を、ハードウェア側から利用できないためです。xHCIでは、この重要な状態の管理をハードウェア側に移すことで、VM間でUSBリソースを管理できるようにしています。さらにxHCIの仮想化機能は、①USBバストポロジー上の位置に関係なく個々のUSBデバイスを任意のVMに直接割り当てること、②実行時のVM間通信を最小限にすること、③ネイティブなUSBデバイス共有をサポートすること、を可能にします。
When USB was originally developed, it was targeted at desktop platforms and performance was the primary objective, which meant that host power consumption was not an important consideration. Since then, mobile platforms have become the platform of choice, and their batteries have made host power consumption and idle time efficiency key considerations. The xHCI elimination of the host memory based transaction schedules and its support for the advanced USB3 power management features are key to providing more power efficient platforms without sacrificing performance.
USBの元祖が開発されていた時、そのターゲットはデスクトッププラットフォームで性能が主要目的であり、ホストの電力消費は重要視されていませんでした。 モバイルプラットフォームがプラットフォームとして選ばれるようになるとバッテリーのホストの電力消費と効率的な停止時間が重要視されるようになりました。 xHCIでは、ホストメモリを使用したトランザクションスケジュールを排除していること、および高度なUSB 3の電力管理機能をサポートしていることが、性能を犠牲にすることなく、より電力効率の高いプラットフォームを実現するうえで重要です。
The storage capacities of portable devices have been increasing with Moore’s Law. Vendors of these devices need high performance interfaces so that these high capacity devices can be loaded in reasonable amounts of time. The Enhanced SuperSpeed support of the xHCI addresses this need.
ポータブルデバイスのストレージの容量はムーアの法則に従い増加していきました。 これらのデバイスのベンダーはその結果高容量デバイスから合理的な時間で読み込みができるように、高パフォーマンスインターフェースを必要としました。
The development of the eXtensible Host Controller Interface was driven by 3 key factors; Speed, Power Efficiency, and Virtualization.
xhciの開発の背景は速度、電力効率、仮想化の3つの鍵となる要素でした。
The abbreviation i.e. is for the Latin phrase id est which means that is. The abbreviation e.g. is for the Latin phrase exempli gratia which means for example.
略語のi.eはラテン語の「すなわち」を意味します。 略語のe.gはラテン語の「例えば」を意味します。
The symbol combination “=>” shall be read as “transitions to”. e.g. OCA => ‘1’ means the value of OCA transitions to ‘1’.
“=>”は~へ変換するという意味です。例えばOCA => ‘1’はOCA変数が1を意味します。
Throughout this document pseudo code is used to illustrate operating principals. Comments are demarcated by the double forward slashes “//”. The pseudo code conventions include: If/else condition statements:
この文書全体を通じて疑似コードは主要な操作を図解するのに使われます。 コメントは//で区切られた部分です。 疑似コードは慣例を含んでいます。
The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted).
mayは標準の制限の中で許可されたものを示します。
The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that).
shouldはいくつかの方法のなかで特に適しているものを選ぶときに使われますが、他の方法を否定するものではありません。shouldの否定形(should not)は非推奨だが禁止されていないものを意味します。
The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.
必須要件を説明するときwillは使用してはいけません、willは事実を並べる時に使われます。
The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).
can という単語は、物質的、物理的、または因果的なものであるかに関係なく、可能性や能力について述べる場合に使用されます。
The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situation s
必須要件を説明するときmustは使用してはいけません、mustは避けられない状況を説明する時に使われます。
Hexadecimal numbers are written with a lower case “h” suffix, e.g., FFFFh and 80h. Hexadecimal numbers larger than four digits are represented with a space dividing each group of four digits, as in 1E FFFF FFFFh. Binary numbers are written with a lower case “b” suffix, e.g., 1001b and 10b. Binary numbers larger than four digits are written with a space dividing each group of four digits, as in 1000 0101 0010b. All other numbers are decimal.
16進数は後ろにhがつきます。例：FFFFh、80h 16進数が四桁を超える場合は1E FFFF FFFFhのようにスペースを空けて表記されます。 2進数は後ろにbがつきます。例：1001b、10b 2進数が四桁を超える場合は1000 0101 0010bのようにスペースを空けて表記されます。 他の数字は10進数です。
Terms or names in bold text indicate the sentence provides a basic xHCI definition of the respective term/name. All other references to an xHCI defined term/name use the exact same text string as the definition so that you can search on it easily. Refer to section 1.5 for more information on searching.
太字の項目か名前は各標準xhciの定義を示す文章です。 その他すべての参照は簡単に検索しやすいように全く同じ書き方で定義されています。検索のさらに詳しい情報はセクション1.5を参照してください。
Implementation Notes should not be considered to be part of this specification. They are included for clarification and illustration only. Implementation Notes within this document are enclosed in a box and set apart from other text.
実装上の注意はxhciの仕様ではありません。 これらは明確化や具体化のためだけに用意されています。 実装上の注意は文中から切り離された箱に書かれています。
The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the xHCI specification and from which no deviation is permitted (shall equals is required to).
shallという言葉が出てきたらそこはxhciのの仕様に準拠するために従わなければならない必須要件である。
Italic text is used to identify Capitalized names that are explicitly named xHCI; registers, register fields, or flags in registers.
斜体文字はxhciで明確に定義された名前を識別するのにつかわれます。例：レジスタ、レジスタフィールド、レジスタフラグ
Adopters can demonstrate compliance of their product(s) with this specification through the xHCI compliance testing program provided by Intel®. For details on the xHCI compliance testing program, please send email to ssusbcompliance@usb.org. The xHCI Compliance Test Suite provides an excellent reference of software expectations when communicating with the xHCI and a concise list of the test validation assertions associated with this specification.
xHCI仕様に従って製品を作った場合、それが本当に仕様に準拠しているかを確認するためのCompliance Testing Programがあります。さらに、そのテストスイートは単なる合否判定用のテストではなく、ソフトウェアがxHCIとやり取りするときにどのような動作をすることが期待されているのかを知るための良い参考資料にもなります。
Some terms are capitalized to distinguish their definition in the context of this document from their common English meaning. Words not capitalized have their common English meaning. When terms such as “memory write” or “memory read” appear completely in lower case, they include all transactions of that type.
いくつかの項目は大文字で表記されそれはこの文書の文脈で定義されており一般的な英語の意味とは区別されます。大文字で表記されていない英語は一般的な意味です。「メモリ書き込み」や「メモリ読み込み」のようなsすべて小文字の項目ではそのままの文字通りのやり取りをします。
Rather than enumerating the full specification name every time one of the above specs are referenced in this document, the abbreviation listed in the Spec Reference column shall be used.
この仕様書で上記の仕様を参照するときフルネームを称せずSpec Reference の略語を使用することとします
Register names and the names of fields and bits in registers and headers are presented with the first letter capitalized and the remainder in lower case.
レジスタ名、フィールド名、レジスタのビット、ヘッダ、は頭文字が大文字でそれ以外が小文字です。
For example: To find all references to the Port Power (PP) field of the PORTSC register, in Reader® open the Search dialog box, and since this field has an acronym, enter the string “PP” in the ‘What word of phrase would you like to search for?’ text box. Check the ‘Whole words only’ and ‘Case-sensitive’ check boxes, and press the ‘Search’ button to list all references to the Port Power flag in this specification in the ‘Results’ window.
PORTSCレジスタのPortPowerフィールドを参照するときReaderのダイアログボックスを開いて略語であるPPを「What word of phrase would you like to search for?」テキストボックスに入力します。 「Whole words only’ and Case-sensitive」チェックボックスにチェックを入れ‘Search’ボタンを押すと‘Resultsウィンドウにこの仕様書のPortPowerフラグの参照がすべてリストアップされます。
This document does not include an index. An effective substitute when viewing with Adobe® Reader® is to use the Search dialog box to locate all references to a specific xHCI feature or field.
このドキュメントには索引がありません。特定のxHCIの機能を参照したいときは検索ダイアログを使用するのが効果的です。
This specification presents a view of the overall architect ure and detailed description of the operational model requirements of the host controller, using the defined registers and interface data structures.
この仕様書ではデータ構造のインターフェースとレジスタの定義を使ったホストコントローラのoperationalモデル要求の詳細な説明とアーキテクチャの全体像を提供します
The specification is primarily targeted to host controller developers and system OEMs, but provides valuable information for platform operating system and BIOS device driver developers, adapter IHVs/ISVs, and platform/adapter controller vendors. This specification can be used for developing new products and associated software.
この仕様書の主要なターゲットはホストコントローラー開発者とシステムoemですが提供される有益な情報はosのプラットフォームとBIOSのデバイスドライバー開発者、IHVs/ISVs、プラットフォーム、アダプターのベンダー向けでもあります。 この仕様書は新しい商品や関連ソフトウェアの開発に使用できます
The following documents are referenced throughout this specification. The Spec Reference defines a shorthand mnemonic used in this specification for the respective document listed below.
以下のドキュメントはこの仕様書全体を言及しています。 Spec Reference はこの仕様書で使われる以下の各ドキュメントの略語です。
The eXtensible Host Controller Interface (xHCI) specification describes the register-level host controller interface for Universal Serial Bus Revision 2.0 and above. The specification includes a description of the hardware/software interface between system software and the host controller hardware.
xhciの仕様書はUSB2.0以上のレジスタレベルのホストコントローラーインターフェースを説明しています。 この仕様書にはシステムソフトウェアとホストコントローラーハードウェア間の説明が含まれます
The architecture (3) and operational (4) sections are followed by two sections of pure structural definitions that detail the register space (5) and interface data structures (6). These definition chapters contain little or no operational requirements or usage models. The final sections describe the xHCI Extended Capabilities (7), and the virtualization operational model (8). The Appendix covers useful information not included elsewhere in the specification.
3章のArchitectureと4章のOperationalの後に、レジスタ空間を定義する5章と、インターフェースのデータ構造を定義する6章があります。5章と6章は「どう動かすか」を説明する章ではなく、「どういう構造になっているか」を定義する章です。その後、7章で拡張機能、8章で仮想化時の動作について説明します。Appendixには、それ以外の補足的な情報が載っています。
This specification is intended for hardware component des igners, system builders and device driver (software) developers. The reader is expected to be familiar with the current Universal Serial Bus Specification revisions. In spite of due diligence, there may exist conflicts between this specification and the US B Specification. The USB Specifications take precedence on all issues of conflict.
この仕様書はハードウェアコンポーネント設計者、システムビルダー、デバイスドライバー開発者用を意図しています。 読者はユニバーサルシリアルバス仕様リビジョンに精通していることが期待されます。 十分に注意・確認を行っているにもかかわらず、この仕様書とUSB仕様書との間に矛盾が存在する可能性があります。すべての矛盾はUSB仕様が優先されます
式変形
両辺は正なので底2の対数をとれる log2N≤log2(2a). 右辺は指数と対数が打消しあって log2N≤2a.
回の場合の計算回数
2を何乗したらNになるか
が成立する。
mで割った余りがbである整数という条件二つを二つにまとめることができる
x≡b1 (mod.m1) x≡b2
mで割った余りがbである整数という条件が二つある
互いに素
2つ以上の整数に共通する約数が「1」しかない状態
Endpoint Context Data Structure
Endpoint Contextのデータ構造
Slot Context Data Structure
Slot Contextのデータ構造
Interrupter Register Set
Event ringのERSTEntryのInterrupter Register Set
Event Ring Segment Table
Event ringのERST
Device Context Base Address Array Pointer - RW. Default = ‘0’. This field defines high orderbits of the 64-bit base address of the Device Context Pointer Array. A table of address pointersthat reference Device Context structures for the devices attached to the host.
デバイスコンテキストベースアドレス配列ポインタ - RW。デフォルト = ‘0’。このフィールドは、デバイスコンテキストポインタ配列の64ビットベースアドレスの上位ビットを定義します。ホストに接続されたデバイスのデバイスコンテキスト構造を参照するアドレスポインタのテーブルです。
Number of Interrupters (MaxIntrs). This field specifies the number of Interrupters implementedon this host controller. Each Interrupter may be allocated to a MSI or MSI-X vector and controlsits generation and moderation.The value of this field determines how many Interrupter Register Sets are addressable in theRuntime Register Space (refer to section 5.5). Valid values are in the range of 1h to 400h. A ‘0’ inthis field is undefined.
割り込み数（MaxIntrs）。このフィールドは、このホストコントローラに実装されている割り込みの数を指定します。各割り込みはMSIまたはMSI-Xベクターに割り当てられ、その生成と制御を制御します。 このフィールドの値は、ランタイムレジスタ空間（セクション5.5を参照）でアドレス指定可能な割り込みレジスタセットの数を決定します。有効な値は1hから400hの範囲です。このフィールドが「0」の場合、 未定義となります。
Number of Device Slots (MaxSlots). This field specifies the maximum number of DeviceContext Structures and Doorbell Array entries this host controller can support. Valid values arein the range of 1 to 255. The value of ‘0’ is reserved.
デバイススロット数（MaxSlots）。このフィールドは、このホストコントローラがサポートできるデバイスコンテキスト構造とドアベルアレイエントリの最大数を指定します。有効な値は 1～255 の範囲です。「0」は予約済みです。
The capability registers specify the limits, restrictions,and capabilities of a host controller implementation.These values are used as parameters to the hostcontroller driver.
capabilityレジスタは、ホストコントローラ実装の制限、制約、および機能を指定します。 これらの値は、ホストコントローラドライバへのパラメータとして使用されます。
(USBCMD)
(USBCMD)
Operational Base + (04h)
(USBSTS) Operational_baseはmmio_base+caplength
Refer to section 3.1 for a summary of the xHCI register architecture
xHCI レジスタ アーキテクチャの概要については、セクション 3.1 を参照してください。
Note that the xHCI does not require support for exclusive -access mechanisms(such as PCI LOCK) for accesses to the memory-mapped register space.Therefore, if software attempts exclusive-access mechanisms to the hostcontroller memory-mapped register space, the results are undefined.
xHCI は、メモリマップ レジスタ空間へのアクセスに排他アクセス メカニズム (PCI LOCK など) のサポートを必要としないことに注意してください。したがって、ソフトウェアがホスト コントローラのメモリマップ レジスタ空間への排他アクセス メカニズムを試行した場合、結果は未定義になります。
The extensible USB Host Controller contains many software accessible hardwareregisters. A large portion of the registers appear as Memory -mapped HostController Registers. Other registers may appear using non-memory addressmechanisms, as in the case of a PCI or PCIe based Host Controller. For thesedesigns it is required to implement the required registers as defined by therespective specification.
xhclにはソフトウェアからアクセス可能なハードウェアレジスタが多数含まれています。レジスタの大部分は、メモリマップドホストコントローラレジスタとして表示されます。PCIまたはPCIeベースのホストコントローラの場合のように、他のレジスタはメモリ以外のアドレスメカニズムを使用して表示されることがあります。これらの設計では、それぞれの仕様で定義されている必要なレジスタを実装する必要があります。
This document describes the EDK II Platform Description file (DSC) format. The EDK Build Tools are included as part of the EDK II compatibility package. In order to use EDK II Modules or the EDK II Build Tools, an EDK II DSC and FDF file must be used.
このドキュメントでは、EDK II プラットフォーム記述ファイル（DSC）形式について説明します。EDK ビルドツールは、EDK II 互換性パッケージに含まれています。EDK II モジュールまたは EDK II ビルドツールを使用するには、EDK II DSC ファイルと FDF ファイルを使用する必要があります。