These are templates for PCIe Extended Capabilities. They are designed to be
applied on a group
. For convenience there exists a template
defining_xyz_capability
for each capability xyz
which defines a group
xyz
with the xyz_capability
applied. Most templates only define the
registers with their standard access restrictions. If additional behavior is
needed, the user of the template must implement this manually.
Each extended capability template uses the following parameters:
base
: Base address of the capability headernext_ptr
: Value of the next_ptr field in the capability headeraer_capability
vc_capability
dsn_capability
dpb_capability
rcld_capability
Uses the following parameters:
num_links
: number of links.rcilc_capability
rcecea_capability
Uses the following parameters:
version
: version number of this capability, default 2mfvc_capability
rcrb_capability
vsec_capability
acs_capability
ari_capability
ats_capability
This is a partially functional template; the user must implement the method
invalidate_received
.
invalidate_received(transaction_t *t, uint64 addr) -> (bool)
Called by the standard PCIe templates when an ATS Invalidate message
is received. The default implementation logs an unimpl
message and
returns false
, indicating a 'Completer Abort'.
memory_read_buf(buffer_t buf, uint64 addr, pcie_at_t at) -> (pcie_error_t, uint32)
Performs a Memory Read with AT field of the TLP header as specified
in the input argument at
. Returns a pcie_error and the pcie
byte-count. Requires that an upstream_target
is defined.
memory_write_bytes(bytes_t bytes, uint64 addr, pcie_at_t at) -> (pcie_error_t)
Performs a Memory Write with AT field of the TLP header as specified
in the input argument at
. Requires that an upstream_target
is
defined.
mc_capability
prs_capability
method page_request(uint64 addr) -> (pcie_error_t)
Sends a Page Request message. The caller is responsible for setting
the Page Address, PRGI, L, W and R fields of the requested
address. Requires that an upstream_target
is defined.
method page_response_received(transaction_t *t, uint64 addr) -> (bool)
Called by the standard PCIe templates when a Page Response message is
received. The default implementation logs an unimpl
message and
returns false
.
rbar_capability
The standard PCIe templates for Base Address Registers automatically find and use the size configured in instances of this template, when enabled.
Uses the following parameters:
num_bars
: Number of resizable bars present in this capability.bar_indexes
: list of integers, setting init_val
of control.id
field for each RBARbar_capabilities
: list of integers, setting init_val
of capability
register for each RBARvf_rbar_capability
This template works just like the Resizable Bar (RBAR) template, but is detected and used by the standard PCIe templates for Virtual Function Base Address Registers instead.
dpa_capability
Uses the following parameters:
num_substates
: number of power allocation registers, default 1tph_capability
Uses the following parameters:
num_tables
: number of TPH ST Table registers, default 1ltr_capability
spe_capability
Uses the following parameters:
max_link_width
: number of Equalization Control registers, no defaultpasid_capability
lnr_capability
dpc_capability
Uses the following parameters:
root_port
: presence of PIO registers, default falsel1pms_capability
Fields to be added upon request.
ptm_capability
Fields to be added upon request
mpcie_capability
frsq_capability
Fields to be added upon request
rtr_capability
Fields to be added upon request
dlf_capability
pl16g_capability
Uses the following parameters:
max_link_width
: maximum link width, no defaultmax_lanes
: maximum number of lanes, no defaultlmar_capability
Uses the following parameters:
max_lanes
: number of lane control and status registers, no defaultpl32g_capability
Uses the following parameters:
max_link_width
: maximum link width, no defaultmax_lanes
: maximum number of lanes, no defaultpl64g_capability
Uses the following parameters:
max_link_width
: maximum link width, no defaultmax_lanes
: maximum number of lanes, no defaultdvsec_capability
hid_capability
npem_capability
ap_capability
Fields to be added upon request
Fields and access restrictions to be added upon request
sriov_capability
This is a partially functional template; users must implement the methods
get_offset
and get_stride
, create an array of DML-objects that simulate
the configuration header for each virtual function, and add instances of the
vf_base_address
template for each VF BAR that is implemented by the
physical function.
Uses the following parameters:
virtual_functions
: array of objects simulating the virtual functions,
typically a bank-array using the vf_type_0_bank
template.get_offset() -> (uint16)
Returns the offset to the first virtual function, must be implemented by the user.
get_stride() -> (uint16)
Returns the stride between virtual functions, must be implemented by the user.
dev3_capability
fl_capability
fpm_capability
Uses the following parameters:
n_lpms
: Number of LTSSM Performance Measurement Status Registers, no defaultfei_capability
sf_capability
Uses the following parameters:
n_sfi
: Number of Shadow Functions Instance Registers, no defaultdoe_capability
Uses the following parameters:
mailbox_len
: Length of request and response mailboxinterrupt_support
: Use interrupts for DOE related eventsmethod response_ready(uint18 res_len)
This method should be called when the incoming DOE request has been finnished processing. This means that if the request requires a response, that should have been written to the provided response buffer. In the case where no response is needed, or silently discarding the request is desried, this method should still be called but with \p res_len set to 0.
@note After this method has been called, neither the request or the response buffer should be accessed.
@note only one of response_error()
and response_ready()
should be
called during the processing of a DOE request.
@param[in] res_len The length of the request
method response_error()
This method should be called when an internal error has been encountered during processing of the DOE request.
@note After this method has been called, neither the request or the response buffer should be accessed.
@note only one of response_error()
and response_ready()
should be
called during the processing of a DOE request.
shared method doe_abort()
This method can optionally be overridden to handle scenarios where doe
requests are aborted.
shared method doe_get_dimn() -> (uint11)
This method can optionally be overridden to control the value of the
"DOE Interrupt Message Number" (dimn) bits. This provides the flexability
to check the "Multiple Message Enable" bits in MSI for example, or other
things might affect what the value of the dimn bits.
template doe_protocol
The doe_protocol template should be used to define user-defined DOE protocols. These should be added to a doe_capability instance accordingly. The way this is done is by adding them to the protocols group in the doe_capability. Example:
template doe_custom_protocol is doe_protocol {
param vendor_id = 0x1234;
param data_object_type = 0;
shared method handle_request(const uint32 *req, uint18 req_len,
uint32 * const res, uint18 res_len) {
return 0;
}
}
bank pcie_config {
...
is defining_doe_capability;
group doe {
group protocols {
group custom_protocol is doe_custom_protocol;
}
}
...
}
shared method handle_request(const uint32 *req, uint18 req_len_dw, uint32 * const res, uint18 res_len_dw);
The implementation of this abstract method should handle a DOE request for
the implemented protocol. This method must at some point (or schedule an
event that at some point) call the method response_ready(res_len)
(or
response_error()
which is defined in the instantiating template
doe_capability. This should be done when the response has been written to
the \p res buffer. The call should contain the length of the response.
@note The size of the response buffer is the param mailbox_len
@param[in] res The request buffer
@param[in] req_len The length of the request
@param[in] req_res The length of the response buffer
@param[out] res The response buffer
ide_capability
null_capability_ext
vf_type_0_bank
Can be used to implement Virtual Functions, used by SR-IOV capability.
Inherits the config_bank
template. Note that this template must use the
vf_base_address
template to implement its Base Address Registers.
vf_base_address
Can be used to implement Base Address Registers in the SR-IOV capability
header. Inherits the template memory_base_address
. Expects the parameter
map_obj
to be an array of mappable objects, one for each Virtual Function.