Patent Description:
The static address regions contain the Control and Status Registers (CSRs) for a specific IP block. The on-SoC IP blocks are not logically attached to an enumerable bus. Rather, their location in the SAM is hard-coded into various informational tables provided to the operating system. The operating system does not have any standardized means to discover and/or enumerate those devices other than using a firmware-maintained table. The operating system does not have any means to control or isolate those on-SoC IP blocks using a Memory Management Unit (MMU) from other system devices or assign them to a guest virtual machine. Device drivers are specific both to a given device and to the SoC that devices reside within.

<CIT> discloses a virtual switch forwarding messages based on the type of a PCI Express configuration message.

The claimed-subject-matter is defined in the independent claims.

Generally disclosed herein is an approach for enabling the connection of non-PCIe devices, such as accelerators, as abstracted PCIe devices using a PCIe abstraction layer ("PAL"). According to this approach, an operating system accesses and configures any on-SoC devices and accelerators using standard PCIe application programming interface (APIs). PCIe configuration transactions may be routed to the PAL. The PAL's firmware may present the operating system with a PCIe topology that contains all available SoC PCIe and abstracted PCIe devices. The firmware of the PAL may translate PCIe configuration transactions into device-specific configuration transactions, which are performed between the PAL and the non-PCIe device. Further, the firmware of the PAL may create a representation of configuration space enabling Single-root I/O Virtualization (SR-IOV) to allow for device virtualization even if such virtualization is not natively supported by the non-PCIe devices. Accordingly, a non-PCIe accelerator may be attached as an abstracted PCIe device without hardware changes and without changing an ordering model of the non-PCIe accelerator.

An aspect of the disclosure provides a method for connecting non-PCIe accelerators as PCIe devices. The method includes receiving, at a firmware-based PCIe abstraction layer ("PAL") for a system, configuration transactions from a core of the system, the configuration transactions for configuring a peripheral device being attached to the system. When the configuration transactions are for a non-PCIe device being attached to the system, the PAL terminates the configuration transactions for the non-PCIe device and configures the non-PCIe devices directly.

In an example, configuring the non-PCIe device directly comprises processing device-specific and function-specific configurations directly with the non-PCIe device.

In yet another example, upon the configuring, the non-PCIe device accesses memory of the system directly using native interfaces and ordering schemes embedded in the non-PCIe device.

In yet another example, the method includes creating, with the one or more processors, a PCIe topology within the PAL, wherein the PCIe topology includes a plurality of PCIe devices and a plurality of abstracted PCIe devices.

In yet another example, the PCIe topology is accessed through an Enhanced Configuration Access Mechanism ("ECAM") to allow management of multiple PCIe configurations by stopping multiple threads from trying to simultaneously access a configuration space.

In yet another example, the method includes creating a PCIe configuration space when virtualization is not natively supported by the one of the plurality of the non-PCIe devices.

In yet another example, the method includes assigning the non-PCIe device to a memory mapped I/O ("MMIO") ranges and configuring a coherent mesh network to map the non-PCIe device to the PAL.

In yet another example, the non-PCIe device is an accelerator, and further comprising implementing an accelerator-specific interface that provides a virtual function separation.

In yet another example, when the configuration transactions are for a PCIe device, the configuration transactions to one or more controllers of the PCIe device are forwarded via a mesh network.

In yet another example, the method includes observing one or more configuration-write transactions to memory by maintaining a copy of a PCIe topology.

In yet another example, the method includes when the configuration transactions are for a PCIe device, forwarding, by the PAL, the configuration transactions to one or more controllers of the PCIe device.

In yet another example, the PCIe configuration space is created using a firmware of the PAL based on a representation of configuration space enabling single-root I/O virtualization (SR-IOV) to allow for device virtualization.

Another aspect of the disclosure provides a system including one or more memories; and one or more processors configured to: receive, at a firmware-based PCIe abstraction layer for a system, configuration transactions from a core of the system, the configuration transactions for configuring a peripheral device being attached to the system. When the configuration transactions are for a non-PCIe device being attached to the system as an abstracted PCIe device, the one or more processors are configured to terminate the configuration transactions for the non-PCIe device and configure the non-PCIe devices directly.

In an example, the one or more processors are configured to process device-specific and function-specific configurations directly with the non-PCIe device.

In yet another example, upon the configuring, the non-PCIe device accesses memory of the system directly using native interfaces and ordering schemes embedded in the non-PCIe device.

In yet another example, the one or more processors are configured to create a PCIe topology within the PAL, wherein the PCIe topology includes a plurality of PCIe devices and a plurality of abstracted PCIe devices.

In yet another example, the one or more processors are configured to create a PCIe configuration space when virtualization is not natively supported by the one of the plurality of non-PCIe devices.

In yet another example, the one or more processors are configured to assign the non-PCIe device to a memory-mapped I/O ("MMIO") ranges and configure a mesh network to map the non-PCIe device to the PAL.

In yet another example, when the configuration transactions are for a PCIe device, the configuration transactions to one or more controllers of the PCIe device is forwarded via a mesh network.

Generally disclosed herein is an approach for enabling the connection of non-PCIe accelerators as PCIe devices. Peripheral devices may include both PCIe devices and non-PCIe devices. The PAL may be a system-on-chip (SoC) Microcontroller. The PAL may communicate with a core, memory, and accelerator through hardware interconnect on-chip, such as a mesh. PCIe configuration transactions are routed to the PAL from the core where PCIe driver software is running.

PAL may provide the PCIe driver software with an interface to an SoC PCIe topology, which may include a mix of PCIe devices and non-PCIe devices that are coupled to the mesh and accessed as "abstracted" PCIe devices. Examples of such abstracted PCIe devices are hardware accelerators, including for example direct memory access (DMA), encryption engines, compression engines, etc. Configuration transactions for PCIe functions are forwarded to respective controllers in the PCIe devices through the PCIe topology. PAL terminates configuration transactions targeting abstracted PCIe devices.

The PAL may implement a virtual configuration space within its own memory space. It may then respond to any configuration reads or writes on behalf of any non-PCIe devices. The PAL may also generate non-PCIe configuration accesses to the non-PCIe devices based on an interpretation of the original PCIe configuration transaction. For example, the PCIe driver software may write to the Function Level Reset (FLR) register in a non-PCIe device's configuration space. The PAL terminates the PCIe transaction and may generate a non-PCIe transaction towards the non-PCIe device which then may write the FLR register. Once configured by the PAL, the non-PCIe device can access the memory directly using its native interface and ordering scheme.

According to some examples, PAL creates a virtual configuration space for each non-PCIe device within the PAL memory. The virtual configuration space may be a representation of a standard PCIe configuration space in the PAL's local memory. The PAL may not necessarily implement all the defined PCIe configuration registers. The PAL may only implement the configuration registers for the ones most relevant to the non-PCIe devices. The firmware creates a PCIe topology that may contain all available SoC PCIe and non-PCIe-based devices. PAL firmware may present the created PCIe topology to the operating system. The PCIe driver software may use standard PCIe configuration transactions to enumerate non-PCIe devices and assign them to memory-mapped I/O (MMIO) ranges. The PAL may configure the SoC's internal interconnect (e.g. internal bus, mesh, NoC, etc.) so that all MMIO ranges initially allocated to non-PCIe devices are mapped to PAL itself. In the virtual PCIe space, PAL may allow and present a single virtual endpoint for each non-PCIe device. Each virtual endpoint may support as many PCIe functions as required by the non-PCIe device that is being abstracted by the PAL.

According to some examples, PAL may handle all the PCIe configuration transactions in the system. The PCIe driver software accesses PCIe configuration spaces through an Enhanced Configuration Access Mechanism (ECAM). The ECAM allows PCIe driver software to access the configuration space of all devices in the PCIe topology. The configuration space available per function is 4KB and the ECAM may map all possible PCIe configuration addresses into a single memory range, such as 128MB, 256MB, 512MB, or other size memory range. Addresses from the ECAM range are mapped to PCIe bus/device/function (BDF) identifiers, so that when software accesses an address range allocated to a specific function, the memory read or write transaction may be routed to the correct device. In this regard, PCIe root ports of PCIe devices may translate the transactions into a PCIe configuration Transaction Layer Protocol (TLP) and send the translated transactions to downstream PCIe devices.

According to some examples, PAL may configure accelerator Message Signaled Interrupt (MSI) definitions based on the configuration transactions generated by the driver software for non-PCIe devices that support MSI generation. The PCIe devices may assert interrupts towards the operating system by using MSI. As the on-SoC non-PCIe device may not support MSI generation, PAL may provide a service to translate line interrupts to MSIs. In some examples, PAL may implement a hardware unit to handle the translation for line interrupts to MSI to avoid having the microcontroller as part of the interrupt path. The PAL's firmware may configure a table based on PCIe configuration transactions targeting a virtual endpoint allocated to each non-PCIe device. Such a table may be used to generate {DeviceID, EventID} on an interface towards software that translated interrupt. Further interrupt processing, such as clearing status bits, may be performed between the non-PCIe device's driver and its hardware directly.

According to other examples, all PCIe or non-PCIe-based reset requests are translated by the PAL into a sequence of actions that may generate the requested reset effect in a specific device. Function level reset handling depends on non-PCIe device-specific implementation. Non-PCIe-level resets are driven by the Power Management support system. Inter-Process Communication (IPC) between the Power Management support system and PAL may be used to communicate reset instructions. A reset may take a PCIe device to a known preliminary state. A reset may be necessary when an error occurs. For example, if a non-PCIe device such as a DMA has <NUM> channels and each channel is connected to <NUM> individual virtual endpoints within the PAL, multiple channels may not need to be reset. The PAL may communicate reset instructions for a single channel through the specific virtual endpoint connected to that specific channel.

According to some examples, Single-root I/O Virtualization (SR-IOV) support relies on specific non-PCIe device implementation. The PAL may implement a virtual configuration space which may include virtual function capabilities assuming the non-PCIe device supports virtualization. The PAL firmware implements an accelerator-specific interface that can provide virtual function separation to ensure that different virtual functions do not impede one another. For example, PAL may dynamically allocate the amount of available DMA engines based on the number of configured virtual functions. If a single virtual function is configured, all available DMA channels may be allocated to that single virtual function. If another virtual function is configured, PAL may split the available DMA channels evenly between the two virtual functions.

According to some examples, PAL does not actively participate in Memory-mapped I/O (MMIO) allocation process for physical PCIe root ports and devices. Configuration transactions pass through PAL, and PAL routes them to the corresponding root ports, but PAL does not modify or observe the contents of these transactions. On the other hand, for abstracted PCIe devices, PAL provides the configuration space interface to PCIe software for the abstracted PCIe devices. For each accelerator, PAL shall provide a Base Address Register (BAR) size requirement based on the specific Accelerator's needs. PAL presents virtual function configuration spaces and BARs for accelerators supporting SR-IOV.

The PAL may be composed of a high-performance processor, wrapper, configuration interface, ingress queue handler, interrupt translation logic, internal data fabric, and address remap unit. The processor monitors enumerations by observing a configuration write (ConfigWr) transaction to Bus/Device/Function (BDF) based on maintaining the shadow PCIe topology. The PAL may then update the SoC's internal system address map based on PCIe MMIO allocation performed during the PCIe and non-PCIe devices' enumeration. The PAL may maintain a copy of the enumerated PCI topology within its memory to monitor which PCIe or non-PCIe devices reside under which port when the PAL needs to route configuration transactions to a specific root port or virtual root port.

According to some examples, the PAL may dynamically change an internal SoC configuration based on PCIe driver software's decisions during enumeration. Such a change may include OS boot. when the OS boots the system, the OS may configure a SoC's internal interconnect with the PAL PCIe's segment range. The OS may enumerate PCIe devices and allocate MMIO spaces in the OS PCIe segment range. When the data flow from the core to a root port of a PCIe device, access permission may be created for an MMIO translation targeting an MMIO space allocated to the root port in the OS PCIe address map. Then, the PAL's "address re-mapping function" may translate the addresses of the root port to PAL's segment addresses.

<FIG> depicts a block diagram of an example platform according to aspects of the disclosure. The PCIe abstraction platform <NUM> includes the PCIe Abstraction Layer (PAL) <NUM>. PAL <NUM>, for example, may be a microcontroller composed of a variety of components such as a processor, an internal configuration fabric, an ingress queue handler, an interrupt translation logic, an interrupt translation service and an address remapping unit. An example detailed architecture of PAL110 is described in further detail below in connection with <FIG>.

PAL <NUM> receives all PCIe configuration transactions originating at the core <NUM>. The core <NUM> may be a CPU core in communication with Memory <NUM>.

The core <NUM> may be a microprocessor residing on a chip, a multi-core processor, or any other known processor. While only one CPU core is shown, any number of CPU cores may be connected. The core <NUM> may include a host or PCIe driver software that configures switch ports to route traffic based on the bus and device numbers.

The memory <NUM> may be any type of memory, such as read-only memory, random access memory, removable storage media, cache, registers, or the like.

The mesh <NUM> may be a hardware interconnect that connects PCIe devices, and non-PCIe devices with the core <NUM> and the memory <NUM>. The mesh <NUM> may be any type of hardware interconnect on a chip. The mesh <NUM> may be configured dynamically based on PCIe's enumeration function.

The PCIe root port <NUM> may be a specific port on a computer's motherboard. The PCIe root port130 may be a port on a root complex, or a portion of the motherboard that contains a host bridge. The host bridge may allow the PCI root ports to communicate with the rest of the computer, thereby enabling the components plugged into the PCIe root ports to work with the computer.

The non-PCIe device <NUM> may be any type of hardware device or software program with the main function of enhancing the overall performance of the computers. The non-PCIe device <NUM> may include a hardware accelerator, a graphics accelerator, a cryptographic accelerator, a web accelerator, a hypertext preprocessor accelerator, or the like.

In some examples, all PCIe configuration transactions may be routed to the PAL <NUM>. Once the PAL <NUM> receives the PCIe configuration transaction information from core <NUM>, the PAL <NUM> may generate an interface to an SoC PCIe topology and provide the host software embedded in core <NUM>. The SoC PCIe topology may include a mixture of PCIe devices, such as a PCIe device connected through PCIe root port <NUM>, and abstracted PCIe devices including the non-PCIe device <NUM>. The configuration transaction directed to the PCIe devices may be forwarded to the PCIe root port <NUM> via the mesh <NUM>. The configuration transactions directed to abstracted PCIe devices is terminated by the PAL <NUM>.

According to some examples, device or function-specific configurations may be handled directly by the firmware embedded in the PAL, as opposed to the non-PCIe device <NUM> accessing the memory <NUM> directly using its native interface and ordering scheme.

<FIG> depicts a block diagram of an example virtual PCIe space presented by PAL according to aspects of the disclosure. According to some examples, the PAL <NUM> may allow the configuration and enumeration of non-PCIe on-SoC devices within the virtual PCIe space <NUM> by creating a virtual configuration space for each non-PCIe device within the PAL memory. The PCIe software of the core <NUM> may use standard PCIe configuration transactions to enumerate the accelerators and assign them MMIO ranges. The PAL <NUM> may configure the mesh <NUM> such that all MMIO ranges allocated to non-PCIe devices, including the non-PCIe device <NUM> by the PCIe software, may be mapped to the PAL <NUM>.

In this example, the OS <NUM> may send the forwarded PCIe configuration transaction <NUM> through the bus <NUM> residing on the PAL <NUM> for each PCIe device <NUM>, <NUM>, <NUM>, and <NUM>. The original memory mapped configuration (MMCFG) address ranges <NUM> may go through the address translation process <NUM> by the PAL <NUM> such that the translated MMCFG address <NUM> is now stored within the memory of PAL <NUM> as statically configured address ranges.

PAL <NUM> may also present to a PCIe software within the core <NUM> a single virtual root port (vRP) <NUM>. Under the vRP <NUM>, the PAL <NUM> may present a single virtual endpoint (vEP) <NUM>, vEP <NUM>, or more virtual endpoints per non-PCIe device including the accelerator <NUM>. Each virtual endpoint, in this example, vEP <NUM> and vEP <NUM>, supports as many virtual functions as supported by one or more non-PCIe devices.

In some other examples, the PAL <NUM> may present Direct Memory Access (DMA) to the OS <NUM> as an SRIOV-capable non- PCIe device residing under the vRP <NUM>. The DMA presented by the PAL <NUM> may support a number of channels, such as <NUM> channels or more. The PAL <NUM> may allow the DMA to support the virtualization of a number of virtual functions corresponding to the number of channels. Channels assignment may be static and managed by the PAL firmware. For example, the PAL <NUM> may allocate a single channel to a single virtual function. During the enumeration process for non-PCIe devices such as the non-PCIe device <NUM>, the PAL <NUM> may request a MMIO range for each virtual function and for each physical function under each virtual endpoint.

<FIG> depict block diagrams of example configuration space mapping according to aspects of the disclosure. In this example, the software running on core <NUM> may access the PCIe configuration space <NUM> via the Enhanced Configuration Access Mechanism (ECAM). ECAM is a mechanism allowing the PCIe to access a configuration space. ECAM may enable the management of multi-CPU configurations. Using the ECAM, the PCIe configuration space <NUM> may be mapped into memory addresses. ECAM may also allow a single command sequence. ECAM may map all possible PCIe configuration addresses into a single memory range.

Bus/Device/Function IDs are eight-bit PCI bus, five-bit device, and three-bit function numbers to identify a PCIe device. In some examples, the addresses from the ECAM range may be mapped to the PCIe Bus/Device/Function IDs. In this regard, when a PCIe driver software requests access to a range allocated to a specific function, such as for a memory read or write transaction, the core <NUM> may route the transaction command to the correct PCIe device. As the PAL <NUM> may handle all PCIe configuration transactions in the system, the ECAM range may be mapped directly to the PAL <NUM>, so the above software access must reach the PAL <NUM> first. PAL <NUM> may remap the ECM address to a new range allocated to a specific PCIe device based on the pre-allocated mapping by the mesh <NUM> and the physical connection of the PCIe device in the system.

In some other examples, the PAL <NUM> may keep track of external PCIe Bus/Device/Function IDs, based on observations of the enumeration operation and keeping a copy of the PCIe configuration topology.

Referring to the example of <FIG>, a single segment in OS memory <NUM> may have a single <NUM> MB memory range. Each block of the single segment in OS memory <NUM> represents 4KB of memory, and it may map the information corresponding to the combination of <NUM> devices, <NUM> buses, and <NUM> functions. The information stored in the single segment in OS memory <NUM> may go through the fabric map process <NUM> and reach the PAL <NUM>. In this process, the address contained in Request Node System Address Map (RN-SAM) <NUM> containing the PCIe initial configuration range is sent directly to the PAL <NUM>. The PAL <NUM> may perform a firmware termination process <NUM> when the PAL <NUM> determines that the Bus/Device/Function ID of a certain transaction matches a virtual root port or endpoint, for example, vRP <NUM>. RN-SAM <NUM> may contain pre-configured ECAM addresses. RN-SAM <NUM> may also contain mapping information of each Bus/Device/Function ID for the corresponding PCIe device's root port, such as PCIe RP <NUM>, <NUM>, and <NUM>.

Referring to <FIG>, the PAL <NUM> may monitor the enumeration of the configuration transactions and update the RN-SAM <NUM> as needed. Since PAL <NUM> is the only initiator of the ECAM targeted addresses, PAL <NUM> is allowed to update only its RN-SAM. In this example, new bus/device/function IDs <NUM> may be updated to the RN-SAM <NUM>. The new bus/device/function IDs <NUM> may be enumerated by the PAL <NUM>. For example, BUS1/DEV0 <NUM> and BUS2/DEV0 <NUM> may be coupled to the PCIe RP <NUM> as a result of the enumeration process, and BUS3/DEV0 <NUM> may be coupled to the PCIe RP <NUM>.

<FIG> depicts a block diagram of an example PCIe abstraction layer architecture according to aspects of the disclosure. Controller <NUM> may be a microcontroller that may include one or more CPUs and memory and programmable input/output peripherals. Internal configuration fabric <NUM> may be used by processor <NUM> to access ingress queue handler <NUM> and interrupt translation logic <NUM>. Internal configuration fabric <NUM> may be a protocol optimized for reducing interface complexity and minimal power consumption for supporting peripheral functions.

Ingress queue handler <NUM> may store the PCIe configuration transactions routed to PAL <NUM>. Once configuration transactions are stored in the ingress queue handler <NUM>, an interrupt may be initiated towards controller <NUM> to signal that a new configuration transaction may be processed. The ingress queue handler <NUM> may also implement a response queue used by controller <NUM> to return the read and write commands toward the mesh <NUM> in <FIG>.

Interrupt translation logic <NUM> may be a table configured by controller <NUM> used to translate line interrupts arriving from the accelerators serviced by the PAL <NUM> to {DeviceID, EventID} attributes passed to the local interrupt interfacing logic <NUM>. In one example, the line interrupts arriving from the accelerators may be blocked using an Access control checker (ACC) <NUM>. ACC <NUM> may provide access control to CSRs of the mesh <NUM> in <FIG> and the controller <NUM>, ingress queue hander <NUM>.

Interrupt interfacing logic <NUM> may be used to forward accelerator interrupts to a generic interrupt controller. Interrupt interfacing logic <NUM> may interact with Internal interface <NUM> through a protocol.

Internal interconnect <NUM> may be a hardware interconnect that may interconnect Controller <NUM>, ingress queue handler <NUM>, and interrupt interfacing logic <NUM>. Internal interconnect <NUM> may contain one or more nodes that may interact with a particular component. For example, Node <NUM> may interact with controller <NUM>, and node <NUM> may interact with ingress queue handler <NUM>.

<FIG> depicts a block diagram of an example functional interrupt handling process by PAL according to aspects of the disclosure. PAL hierarchy <NUM> includes PAL <NUM>, interrupt translation logic <NUM>, and interrupt interfacing logic <NUM>. As for the non-PCIe devices that may support Message-signaled Interrupts (MSIs) generation, PAL <NUM> may configure the non-PCIe device <NUM> MSIs based on the configuration transactions generated by the software running on the core <NUM>. However, when the non-PCIe device <NUM> only supports line interrupts, a dedicated interrupt translator may be implemented. In this example, PAL <NUM> may configure interrupt translation logic <NUM> to configure a dedicated interrupt translator for the line interrupts.

In some other examples, PAL <NUM> may provide a service to translate the line interrupts to MSIs. To avoid having a microcontroller as part of the interrupt path, PAL <NUM> may implement a hardware unit to handle the translations of the line interrupts to MSIs. PAL <NUM> firmware may configure the table generated by interrupt translation logic <NUM> based on PCIe configuration transactions targeting the virtual endpoints allocated to each accelerator.

<FIG> depicts a block diagram of an example PAL address remap function according to the aspects of the disclosure. For example, when the OS boots, the boot process may configure the mesh with PAL PCIe segment address map <NUM>. The OS may enumerate PCIe devices attached through the mesh and allocate MMIO spaces in the OS PCIe segment address map <NUM>.

When an access point of a PCIe root port creates an MMIO transaction targeting an MMIO space allocated to the PCIe root port in the OS PCIe segment address map <NUM>, the transaction may be routed through the mesh to PAL. PAL Address Remap Function <NUM> then may translate the address of the targeted MMIO space to the PCIe segment address map <NUM>. The translation may then be routed through the mesh to the root ports, RP0 <NUM> through RP12 <NUM>.

<FIG> depicts block diagrams of example virtual machine mapping process utilizing PAL according to the aspect of the disclosure. Referring to <FIG>, VM <NUM> includes a DMA driver <NUM>. VM <NUM> may interact with MMU <NUM> by translating its virtual address to an internet protocol address and sending it to MMU <NUM>. While only one VM <NUM> is shown in <FIG>, it should be understood that multiple VMs may communicate with the DMA <NUM> through the PAL <NUM>.

MMU <NUM> may be a memory management unit. The memory management unit may perform the translation of a virtual memory address to a physical address. In this example, MMU <NUM> may translate the received internet protocol address to the physical address and send it to a non-PCIe device such as a direct memory address DMA <NUM>. DMA <NUM> may handle the details of a memory transfer to a peripheral device on behalf of the processor.

DMA <NUM> may include CSR <NUM> and CSR <NUM>. CSR may be a control and status register that resides in the CPU to store information about instructions received from the PCIe or non-PCIe devices.

PAL <NUM> may act as a functional virtual machine separator that may abstract or limit access to functions that may not be accessible to a guest OS and to channels not allocated to particular virtual machines.

For example, when software running on VM <NUM> generates a read or write command to the DMA range in its own virtual address spaces, MMU <NUM> may translate the address. MMU <NUM> may translate the address from each VM's DMA range to a separate range which may be configured in the mesh to be routed to PAL <NUM>. Based on the addresses provided with the transaction, PAL <NUM> may extrapolate an identifier for the VM <NUM> and perform any abstraction or access control action. PAL <NUM> may then translate the address provided to the DMA <NUM> address range and store the address in one of the control and status registers, CSR <NUM>.

<FIG> depicts a flow diagram of an example method of connecting non-PCIe devices as abstracted PCIe devices using PAL. According to block <NUM>, PAL receives configuration transactions from a core of a computer system. According to some examples, the configuration transactions may include configuring a peripheral device being attached to the system.

According to block <NUM>, PAL determines whether the peripheral device attached to the system is a PCIe device or a non-PCIe device. If PAL determines that the peripheral device is a PCIe device, then it proceeds to block <NUM>. If PAL determines that the peripheral device is a non-PCIe device, then it proceeds to block <NUM>.

According to block <NUM>, PAL forwards the configuration transactions received from the core to PCIe devices.

According to block <NUM>, PAL terminates the configuration transactions when the peripheral device is a non-PCIe device.

According to block <NUM>, PAL configures the non-PCIe device as an abstracted PCIe device. According to some examples, PAL may generate a virtual root port with one or more virtual endpoints to communicate transactions with the non-PCIe device. PAL may generate a PCIe topology that may contain all connected PCIe devices and abstracted PCIe devices. PAL may also implement a virtual configuration space within its own memory space, such that PAL may respond to any configuration reads or writes on behalf of the abstracted PCIe devices. Therefore, PAL may provide a fully standardized mechanism through which an operating system and application software may discover and program the abstracted PCIe devices in the same manner as PCIe devices, such that function and device reset, device assignment, and platform error handling flow can be achieved more effectively and efficiently.

Although the technology herein has been described with reference to particular examples, it is to be understood that these examples are merely illustrative of the principles and applications of the present technology.

Claim 1:
A method for connecting non-Peripheral Component Interconnect Express, non- PCIe, accelerators as Peripheral Component Interconnect Express, PCIe, devices, the method comprising:
receiving (<NUM>), at a firmware-based PCIe abstraction layer, PAL (<NUM>), for a system, configuration transactions from a core (<NUM>) of the system, the configuration transactions for configuring a peripheral device being attached to the system;
when the configuration transactions are for a PCIe device, forwarding, by the PAL (<NUM>), the configuration transactions to one or more controllers of the PCIe device; and
when the configuration transactions are for a non-PCIe device (<NUM>) being attached to the system:
terminating (<NUM>), by the PAL (<NUM>), the configuration transactions for the non-PCIe device (<NUM>); and
configuring (<NUM>), directly by the PAL (<NUM>), the non-PCIe device (<NUM>) as an abstracted PCIe device.