Why is the I2C Avalon® Memory Mapped FPGA Host Bridge not writing to On-Chip RAM correctly when using Quartus® Prime Pro Edition Software?
Description When using the Avalon® Memory Mapped Host Bridge Core for writing into On-Chip RAM, the data might get lost or incorrectly written into memory. This behavior can be observed when writing a stream of 4 bytes to memory in certain memory offsets, in some cases, the fourth byte will not be written or misplaced into the i2c_avalon_master_address signal. This problem occurs because of the following reasons: A mishandling of an illegal byteenable condition being issued, described in the Altera® FPGA I2C Agent to Avalon Memory Mapped Host Bridge Core > Write Operation documentation. A mishandling of a multiple write burst condition or split write state performed by the Avalon Memory Mapped Host Bridge Core. This problem was found in the Quartus® Prime Pro Edition Software version 19.1 for Linux*. Resolution To overcome the problem, download the Latest Device Firmware for the Quartus® Prime Pro Edition Software version 22.2 from the following knowledge article: https://community.altera.com/kb/knowledge-base/what-is-the-latest-device-firmware-for-the-agilex%c2%ae-fpga-and-stratix%c2%ae10-fpgas/341066 This problem is fixed in the Quartus® Prime Pro Edition Software v22.3 and Quartus® Prime Standard Edition Software v22.1 onwards.Why does the GTS SDI II IP observe a Single Rate (SR) Dual Simplex (DS) port failure when migrating from an older version of the SR DS Design Example to Quartus® Prime Pro Edition Software version 25.1?
Description Due to a problem in the Quartus Prime Pro Edition software version 25.1, you may observe the Dual Simplex(DS) port failure in GTS SDI II IP when migrating an SR DS design generated by a former version to the Quartus Prime Pro Edition software version 25.1. This is because the Dual Simplex port name changes. Resolution To work around this problem, modify the GTS SDI top level file (sdi_ii_agi_demo.sv) in example_design/rtl/ path. Example: SDI II Wrapper = Both Base and PHY sdi_rx_inst0_auto_rx_cdr_refclk -> rx_cdr_refclk_sdi_rx_inst0 SDI II Wrapper = Base only dphy_rx_inst0_auto_i_rx_cdr_refclk_p -> i_rx_cdr_refclk_p_dphy_rx_inst0 Additional Information This list of port name changes can be found in this link.
Why does my EMIF IP RDIMM design have invalid assignments for SDA/SCL signals after compilation?
Description Due to a problem in the Quartus® Prime Pro Edition software versions 25.1.1, 25.3, and 25.3.1, the Fitter does not automatically place the I2C SDA/SCL signals when they are not explicitly assigned. Resolution To work around the problem, manually assign legal locations for the following signals on the AC1 lane: SDA: index 10 SCL: index 11 For details, see the “Address and Command Pin Placement” table in the External Memory Interfaces Agilex™ 7 M‑Series FPGA IP User Guide (DDR5): Address and Command Pin Placement. Additional Information Affected Quartus® Prime versions: 25.1.1 25.3 25.3.1 This problem is currently scheduled to be resolved in a future release of the Quartus ® Prime Pro Edition Software.Why does the Multi Channel DMA for PCI Express* FPGA IP fail to upgrade in Quartus® Prime Pro Edition Software version 25.3?
Description Due to a name change in the PIO Example Design from “PIO using MQDMA Bypass mode” to “PIO using MCDMA Bypass mode”, designs that include the Multi Channel DMA for PCI Express* FPGA IP created in Quartus® Prime Pro Edition Software versions earlier than 25.3 may fail to generate HDL when performing an automatic IP upgrade. When this problem occurs, the following system error messages appear in the IP Parameter Editor Pro window: Error: intel_pcie_ftile_mcdma_0.intel_pcie_ftile_mcdma_0: "Based on parameterization, the generated example design for PCIe0 will be" (select_design_example_hwtcl) "PIO using MQDMA Bypass mode" is out of range: "Device-side Packet loopback", "PIO using MCDMA Bypass mode", "Packet Generate/Check", "AVMM DMA", "Traffic Generator/Checker", "External Descriptor Controller", "BAM SRIOV" Resolution Workaround: To work around this problem, follow the steps below: Manually update the .ip file in your project by replacing all instances of “PIO using MQDMA Bypass mode” with “PIO using MCDMA Bypass mode.” Save the updated .ip file. Reopen the modified .ip file in the Quartus® IP Parameter Editor. Depending on your use case, click “Generate Example Design” or “Generate HDL.”Why am I seeing some packet drop/loss when using the F-tile Ethernet Hard IP with Auto-Negotiation and Link Training (AN/LT) enabled 100G designs?
Description Due to a problem in the Quartus® Prime Pro Edition software version 25.1.1, 25.3 and 25.3.1, you may see traffic failures with packet drop/loss when using the F-tile Ethernet Hard IP with Auto-Negotiation and Link Training (AN/LT) enabled 100G designs. Resolution Add the solution or the workaround to fix the problem or bug. Additional Information Currently there is no workaround for this problem. This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition software.Why am I seeing linkup problem for the GTS Ethernet Hard IP with Auto-Negotiation and Link Training (AN/LT) multirate IP for HVIO PLL enabled 25G rate designs?
Description Due to a problem in the Quartus® Prime Pro Edition software version 25.3.1, you may see linkup problem for the GTS Ethernet Hard IP with Auto-Negotiation and Link Training (AN/LT) multirate designs. This problem may happen when using 25G multirate designs with HVIO PLL option enabled. Resolution Currently there is no workaround for this problem. This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition software.Why o_rx_pcs_fully_aligned does not assert for 40GE-4 Advanced mode F-Tile Ethernet Hard IP design when Custom Ethernet line rate > 63Gbps?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 25.3 and earlier, you might observe o_rx_pcs_fully_aligned does not assert for the F-Tile Ethernet Hard IP design with below configurations: Advanced mode: Enabled Ethernet mode: 40GE-4 Custom Ethernet line rate: > 63 Gbps Resolution There is no workaround. There is no fix planned in the future. When advanced mode enabled for 40GE-4 design, supported custom Ethernet line rate is: 41.25~63 Gbps.Why am I seeing Deterministic Latency Accuracy problems when using Inter-protocol Designs in the GTS Dynamic Reconfiguration Controller IP?
Description Due to a problem in the Quartus® Prime Pro Edition software version 25.3 and earlier, you may inter-protocol GTS Ethernet Hard IP with PTP and GTS CPRI IP in GTS Dynamic Reconfiguration Controller IP designs. Resolution Currently, there is no workaround for this problem. This problem is scheduled to be fixed in the future release of the Quartus® Prime Pro Edition software. Related IP Core GTS Dynamic Reconfiguration Controller IP GTS Ethernet Hard IP with PTP GTS CPRI IPWhy is the o_rx_pfc port enabled for longer durations than normal when generating designs at 400G SIP using the F-Tile Ethernet Hard IP with Priority Flow Control (PFC) enabled?
Description Due to a problem in the Quartus® Prime Pro Edition software version 25.3, you may see longer durations of “o_rx_pfc” port enabled in the example designs generated using the F-Tile Ethernet Hard IP at data rates of 400G SIP with PFC enabled. When PFC is enabled, if packets received are more than the maximum configured frame size of the receiver, along with which if packet truncation is also enabled on the receiver side, then the packets are truncated, causing data_valid to deassert. This deasserted data_valid signal is affecting the counters of o_rx_pfc to stretch the pause signal duration. Resolution This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition software.Why does the MAC TX of the F-Tile Ethernet FPGA Hard IP halt its transmission of control frames (0x8808) upon receiving PAUSE frames from the link partner?
Description According to Annex 31B.1 of the IEEE802.3 specification, it is noted that the pause operation does not inhibit the transmission of MAC control frames. However, the current implementation of the F-Tile Ethernet FPGA Hard IP mechanism for handling Ethernet frames is not aligned with this specification, as we pause the transmission of all Ethernet frames indiscriminately, regardless of their type. Users wishing to transmit PFC or SFC frames can utilize the SFC/PFC frame generation within HIP, facilitated by register configuration. It's important to note that while our system supports these specific frames, the IEEE specification includes a broader range of control frame types, as outlined in Annex 31A, which HIP does not generate. Alternatively, customers can configure the F-Tile Ethernet FPGA Hard IP to not halt traffic transmission upon receiving Pause frames. Instead, they can utilize the o_pause signal to make transmission decisions at the user end, particularly regarding the transmission of any control frames. Resolution There is no workaround for this problem.