Visible to Intel only — GUID: nik1410905527105
Ixiasoft
Visible to Intel only — GUID: nik1410905527105
Ixiasoft
5.2. Component-Specific Avalon-ST Interface Signals
Signal |
Direction |
Description |
---|---|---|
Avalon-ST TX Physical and Virtual Function Identification Signals | ||
tx_st_pf_num[1:0] | Input | Identifies the Physical Function originating the TLP being transmitted on the TX Stream Interface. The user must provide the originating Function number on this input when transmitting memory requests, Completions, and messages routed by ID. When the originating Function is a VF, this input must be set to the PF Number the VF is attached to. This input is sampled by the SR-IOV bridge when tx_st_sop and tx_st_valid are both high. |
tx_st_vf_active | Input | The Application Layer must assert this input when transmitting a TLP driven by a Virtual Function on the TX Stream Interface. The SR-IOV bridge samples this signal when tx_st_sop and tx_st_valid are both asserted. |
tx_st_vf_num[10:0] | Input | Identifies the Virtual Function driving the TLP being transmitted on the Avalon-ST TX interface. The Application Layer must provide the VF number offset of the originating Function on this input when transmitting memory requests, Completions, and messages routed by ID. Its value ranges from 0-<n>-1 where <n> is the number of VFs in the set of VFs attached to the associated PF. Up to 2048 VFs are supported. The SR-IOV bridge samples this signal when when tx_st_sop, and tx_st_valid, and are asserted. Not used when a PF is driving the TLP. |
Avalon-ST TX Credit Signals | ||
tx_cred_data_fc[11:0] | Output |
Data credit limit for the received FC completions. Each credit is 16 bytes. There is a latency of two pld_clk clocks between a change on tx_cred_fc_sel and the corresponding data appearing on tx_cred_data_fc and tx_cred_hdr_fc. |
tx_cred_fc_hip_cons[5:0] | Output |
Asserted for 1 cycle each time the Hard IP consumes a credit. These credits are from messages that the Hard IP for PCIe generates for the following reasons:
This signal is not asserted when an Application Layer credit is consumed. For optimum performance the Application Layer can track of its own consumed credits. (The hard IP also tracks credits and deasserts tx_st_ready if it runs out of credits of any type.) To calculate the total credits consumed, the Application Layer can add its own credits consumed to those consumed by the Hard IP for PCIe. The credit signals are valid after the dlup (data link up) is asserted. The 6 bits of this vector correspond to the following 6 types of credit types:
During a single cycle, the IP core can consume either a single header credit or both a header and a data credit. |
tx_cred_fc_infinite[5:0] | Output |
When asserted, indicates that the corresponding credit type has infinite credits available and does not need to calculate credit limits. The 6 bits of this vector correspond to the following 6 types of credit types:
|
tx_cred_fc_sel[1:0] | Input |
Signal to select between the tx_cred_hdr_fc and tx_cred_data_fc outputs. There is a latency of two pld_clk clocks between a change on tx_cred_fc_sel and the corresponding data appearing on tx_cred_data_fc and tx_cred_hdr_fc. The following encoding are defined:
|
tx_cred_hdr_fc[7:0] | Output |
Header credit limit for the FC posted writes. Each credit is 20 bytes. There is a latency of two pld_clk clocks between a change on tx_cred_fc_sel and the corresponding data appearing on tx_cred_data_fc and tx_cred_hdr_fc. |
tx_cons_cred_select | Input | When 1, the output tx_cred_data* and tx_cred_hdr* signals specify the value of the hard IP internal credits-consumed counter. When 0, tx_cred_data* and tx_cred_hdr* signal specify the limit value. This signal is present when you turn On Enable credit consumed selection port in the parameter editor . |
The following table describes the signals that comprise the completion side band signals for the Avalon-ST interface. The Arria® 10 Hard IP for PCI Express provides a completion error interface that the Application Layer can use to report errors, such as programming model errors. When the Application Layer detects an error, it can assert the appropriate cpl_err bit to indicate what kind of error to log. If separate requests result in two errors, both are logged. The Hard IP sets the appropriate status bits for the errors in the Configuration Space. It also automatically sends error messages in accordance with the PCI Express Base Specification. Note that the Application Layer is responsible for sending the completion with the appropriate completion status value for non-posted requests. Refer to Error Handling for information on errors that are automatically detected and handled by the Hard IP.
For a description of the completion rules, the completion header format, and completion status field values, refer to Section 2.2.9 of the PCI Express Base Specification.
Signal |
Direction |
Description |
---|---|---|
cpl_err[6:0] | Input |
Completion error from a PF or VF This signal reports completion errors to the Configuration Space. The SR-IOV Bridge responds to the assertion of these bits by logging the status in the error reporting registers of the Function and sending error messages when required. When an error occurs, the appropriate signal is asserted for one cycle. The individual bits indicate following error or status conditions:
|
cpl_err_pf_num[<n>-1:0] | Input | Identifies the Function reporting the error oncpl_err inputs. When the Function is a VF, this input must specify the PF Number to which the VF is attached. |
cpl_err_vf_active | Input | Indicates that the Function reporting the error is a Virtual Function. When this input is asserted, the VF number offset of the Function must be provided on cpl_err_vf_num[10:0]. |
cpl_err_vf_num[10:0] | Input | Whencpl_err_vf_active is asserted, this input identifies the VF number offset of the Function reporting the error. Its value ranges from 0-<n>-1, where <n>is the number of VFs in the set of VFs attached to the associated PF. |
cpl_pending_pf[<n>-1:0] | Input | Completion pending from the PF. The Application Layer must assert this signal when a PF has issued one of more Non-Posted transactions waiting for completions. For example, when a Non-Posted Request is pending from PF0. cpl_pending_pf[0] records pending completions for PF0. cpl_pending_pf[1] records pending completions for PF1. |
log_hdr[127:0] | Input | When any of the bits 2, 3, 4, 5 of cpl_err is asserted, the Application Layer may provide the header of the TLP that caused the error condition. The order of bytes is the same as the order of the header bytes for the Avalon-ST streaming interfaces. |
vf_compl_status_update | Input | Completion status update from the VF. The Application Layer must assert vf_compl_status_update whenever the Completion Pending status changes in a VF, The Application Layer must assert vf_compl_status_update until the SR-IOV bridge responds by setting vf_compl_status_update_ack. |
vf_compl_status | Input | Must be set to the current Completion Pending status of the associated Function whenvf_compl_status_updateis asserted, The following encodings are defined:
|
vf_compl_status_pf_num[<n>-1:0] | Input | Must be set to the PF number associated with the signaling Function when vf_compl_status_updateis asserted, <n> is the number of PFs. |
vf_compl_status_vf_num[<n>-1:0] | Input | Must be set to the VF offset associated with the signaling Function when vf_compl_status_update is asserted, <n> is the number of VFs. |
vf_compl_status_update_ack | Output | The SR-IOV Bridge asserts vf_compl_status_update_ack for 1cycle when it has completed updating its internal state in response to vf_compl_status_update. The Application Layer must assert vf_compl_status_update high until vf_compl_status_update_ack is asserted. |