Why does the RX application interface or outgoing TX packets get corrupted when dynamically changing either the RX or TX MAC configuration register settings on the F-tile Ethernet FPGA Hard IP? - Why does the RX application interface or outgoing TX packets get corrupted when dynamically changing either the RX or TX MAC configuration register settings on the F-tile Ethernet FPGA Hard IP? Description Due to a problem in the Quartus® Prime Pro edition software version 25.1 and earlier, dynamically changing the RX MAC configuration register settings on a live system can cause the RX application interface to become corrupted. Similarly, dynamically changing the TX MAC configuration register settings can cause the transmitted TX packets to become corrupted. Resolution To work around this problem, you can use the IP GUI to statically set the MAC configuration options in your variant. However, if your application requires a dynamic change to the MAC configuration options, please follow the guidance below. Following a change to any RX MAC configuration register setting, assert and deassert “i_rx_rst_n” (or its associated CSR register). Note that any data received on the RX application bus should be ignored until after this reset has been applied. Similarly, following a change to any TX MAC configuration register setting, assert and deassert “i_tx_rst_n” (or its associated CSR register). Note that any packets transmitted by the TX MAC should be dropped by the link partner until after this reset has been applied. This problem is not scheduled to be fixed. Custom Fields values: ['novalue'] Troubleshooting 16027751742 False ['F-Tile Ethernet Hard IP'] ['FPGA Dev Tools Quartus® Prime Software Pro'] novalue 25.1 ['Agilex™ 7 FPGAs and SoCs'] ['novalue'] ['novalue'] ['novalue']