Issue: 361429 Chapter 5 "PCI Express Reconfiguration Block Signals—Hard IP Implementation"
The required maximum frequency of avs_pcie_reconfig_clk in PCIe® IP is 50MHz. Using a higher frequency will cause setup timing violations on the dprioout bus.
Issue: 336210 Chapter 5 "Signals"
Please ignore the following sentence on page 5-1 of the PCI Express User Guide:
"The hard IP implementation is not available for designs using the Avalon-MM interface."
Issue: 309948 Chapter 4 "Functional Description": Clocking Section
Under the clocking section of the document the following configurations are discussed:
- MegaWizard™ Plug-In Manager Design Flow Clocking—Hard IP Implementation
- MegaWizard Plug-In Manager Design Flow Clocking—Soft IP Implementation
- SOPC® Builder Design Flow Clocking—Soft IP Implementation
There is no section to discuss SOPC Builder Design Flow Clocking—Hard IP Implementation
The information in the "SOPC Builder Design Flow Clocking—Soft IP Implementation " is applicable to the Hard IP implementation as well.
Issue: 309946 Chapter 4 "Functional Description": Clocking Section
Figure 4–23. SOPC Builder - Separate Clock Domains is missing information.
This figure should show two clock inputs to the PCI Express Megacore ® Avalon ® MM block. The two clock inputs, Ref_clk and clk, are discussed in Table 5–39. Avalon-MM Clock Signals but not shown in the figure 4-23.
Issue: 307753 Chapter 5 "Signals": Avalon-ST Interface Section
The description for the rx_st_bardec0 signal in Table 5–2. 64- or 128-Bit Avalon-ST Rx Datapath States the following:
"The decoded BAR bits for the TLP. They correspond to the transaction layer's rx_desc[135:128]. They are valid on the 2nd cycle of rx_st_data0. "
The document is correct for a 64-bit datapath and the descriptor will consume 2 clock cycles.
The above statement does not apply to a 128-bit interface. With a 128-bit datapath, the whole descriptor should only take 1 clock cycle, so bardec is not valid on the 2nd cycle.
Issue: 314540 Chapter 5 "Signals": Avalon-ST Interface Section
Table 5-16 shows that a 12 bit signal (cfg_np_bas[11:0]) is squeezed into an 8 bit field. This information is incorrect. cfg_np_bas is a 12-bit signal. Correct mapping of the address 7 (DW 7) in Table 5-16 is as following:
Bits[31:24] = all 0's
Bits[23:12] = tl_cfg_ctl[23:12]
Bits[11:0] = cfg_np_lim[11:0]
Issue: 321267 Chapter 5 "Signals": Reset Signals Section
Table 5–8. Reset Signals (Part 2 of 2) discusses the reset_status signal, but does not provide details on how the signal is derived.
The following text will be included in the Quartus II version 9.1 release of the User Guide:
"The reset_status signal is a function of srst and crst. When one of these two signals asserts, reset_status is asserted. When the npor signal asserts, reset_status is reset to zero."
Issue: 321274 Chapter 4 "Functional Description " : Architecture Section
Transaction Ordering Rules are detailed in Table 4–2.
This section will be updated with the following text in the Quartus II version 9.1 release of the user guide, "MSI request are conveyed in exactly the same manner as PCI Express Memory Write request and are indistinguishable from them in terms of flow control, ordering, and data integrity."
Issue: 321277 Chapter 4 "Functional Description" ECRC Section
Information on how the user application indicates that there has been a ECRC error to the core when the ECRC forwarding is enabled is missing from the user guide. The following information will be added to the Quartus II version 9.1 release of the User Guide, " When the application detects an ECRC error, it should send the ERR_NONFATAL message TLP to the PCI Express MegaCore function to report the error.
For more information about error handling, refer to the Error Signaling and Logging which is Section 6.2 of the PCI Express Base Specification, Rev. 2.0."
Issue: 321281 Chapter 5 "Signals": Reset Signals Section
Information regarding which clock the reset_status signal is synchronous to is missing from the user guide. The following information will be added to the Quartus II version 9.1 release of the user guide, " the reset_status signal is synchronous with the pld_clk. So the reset_status signal will be deasserted only when pld_clk is stable."
Issue: 321282 Chapter 5: "Signals" Completion Side Band Signals Section
The cpl_err[6..2] Descriptions will include the updated information below in the Quartus II version 9.1 release of the user guide:
cpl_err[2]:Completer abort error. The application asserts this signal to respond to a posted or non-posted request with a completer abort (CA) completion. In the case of a non-posted request, the application generates and sends a completion packet with completer abort (CA) status to the requestor and then asserts this error signal to the MegaCore function. The MegaCore function automatically sets the error status bits in the configuration space register and sends error messages in accordance with the PCI Express Base Specification.
cpl_err[3]:Unexpected completion error. This signal must be asserted when an application layer master block detects an unexpected completion transaction. Many cases of unexpected completions are detected and reported internally by the transaction layer of the MegaCore function. For a list of these cases, refer to "Errors Detected by the Transaction Layer" on page 4–54.
cpl_err[4]: Unsupported request error for posted TLP. The application asserts this signal to treat a posted request as an unsupported request (UR). The MegaCore function automatically sets the error status bits in the configuration space register and sends error messages in accordance with the PCI Express Base Specification. Many cases of unsupported requests are detected and reported internally by the transaction layer of the MegaCore function. For a list of these cases, refer to "Errors Detected by the Transaction Layer" on page 4–54.
cpl_err[5]: Unsupported request error for non-posted TLP. The application asserts this signal to respond to a non-posted request with an unsupported request (UR) completion. In this case, the application sends a completion packet with the unsupported request status back to the requestor, and asserts this error signal to the MegaCore function. The MegaCore automatically sets the error status bits in the configuration space register and sends error messages in accordance with the PCI Express Base Specification. Many cases of unsupported requests are detected and reported internally by the transaction layer of the MegaCore function. For a list of these cases, refer to "Errors Detected by the Transaction Layer" on page 4–54
cpl_err[6]: Log header. When asserted, logs err_desc_func0 header. Used in both the soft IP and hard IP implementation of the MegaCore function that use the Avalon-ST interface. When asserted, the TLP header is logged in the AER header log register if it is the first error detected. When used, this signal should be asserted at the same time as the corresponding cpl_err error bit (2, 3, 4, or 5). In the soft IP implementation, the application presents the TLP header to the MegaCore function on the err_desc_func0 bus. In the hard IP implementation, the application presents the header to the MegaCore function by writing the following values to 4 LMI registers before asserting cpl_err[6]:
¨lmi_addr: 12'h81C, lmi_din: err_desc_func0[127:96]
¨lmi_addr: 12'h820, lmi_din: err_desc_func0[95:64]
¨lmi_addr: 12'h824, lmi_din: err_desc_func0[63:32]
¨lmi_addr: 12'h828, lmi_din: err_desc_func0[31:0]
Refer to the "LMI Signals—Hard IP Implementation" on page 5–34 for more information about LMI signalling.
For the × soft IP, only bits [3:1] of cpl_err are available. For the ×, × soft IP implementation and all widths of the hard IP implementation, all bits are available.
Issue: 323073 Chapter 5: "Signals " Avalon-ST Interface Section
The inputs listed below are documented as "for simulation only"in the PCI Express Compiler user guide, but there is no mention on how to connect them in your RTL.
p_clk_in
rxdata0_ext
rxdatak0_ext
rxvalid0_ext
phystatus_ext
rxelecidle0_ext
rxstatus0_ext
The following text will be included in the Quartus II version 9.1 release of the user guide, " For variants that use the internal transceiver, these signals are for simulation only. For Quartus II software compilation, these pipe signals can be left floating. "