Queries on 46.6944 Gbps PAM4 F-Tile Configuration and Loopback Testing using Agilex7
Team, Quartus: Quartus Prime Pro 26.1.0 I am currently working on an Agilex 7 F-Tile transceiver configuration for a 46.6944 Gbps PAM4 application. Please find my query (Read file) as attached and provide advise.. Regards amolkumar
Looking for example testbench for Cyclone-V Transceiver Custom_PHY IP from UG-01080-1.7
Hi, I am looking into the Altera Transceiver PHY IP Core User Guide, UG-01080-1.7 (June 2012). I followed section 7, “Custom PHY IP Core” to generate a custom PHY core using the Quartus 23.1-based MegaWizard and IP Catalog for my Cyclone-V FPGA. I have all Verilog files generated for the custom PHY IP in a new folder tst_xcvr_phy_custom. Next, I tried to do a basic loopback simulation of this custom PHY core. Page 7-28 in the user guide states : ............ However when I try the "Altera wiki" link I get .... not sure why I get this, I do have an active Altera account. Perhaps this Altera-Wiki has been migrated to a Github Altera Transceivers (PHY IP) examples repo ? Can someone help me get an example testbench for the Cyclone-V custom PHY IP ? I have QuestaSim and ModelSim for simulating with it.
Agilex-5 supported Transceivers
I am currently evaluating the capabilities of the Altera Dev Board DK-A5E065AB32AEA. As most SFP+ and QSFP+ Transceivers are often vendor-locked, is there a list of qualified Transceivers available? Intel E10GSFPSR and another Xcvr marketed as support for Nvidia did not work in my case, as I attempted to do the initial Testing using BTS App as per document D554638 Which transceivers were used by Intel(Altera) for qualifiying/testing the development board DK-A5E065AB32AEA ?Agilex5 transceiver in 64/66b mode
Hi, I'm working on a design to implement a high speed bidirectional interface using POC. To achieve highest throughput we should use 64/66 scrambling (which Agilex5 XCVR supports). It doesn't seem clear to me how to config the data bus and what option to select to run the XCVR in that mode. when I select PCS66, I need to provide scrambled data (i.e. build my 64/66 scambler myself). Selecting IEEE_MII port mapping is an Ethernet interface - which I don't want. So that's no option. Selecting FLEXE_66 - well, again 66-bit bus meaning I need to scramble the data myself. Can somebody explain how to get the internal scrambler to operate and how to map 64bit data from logic to the Tx_Parallel(79:0) bus? What am I missing?
Problem with alt_2p5g_phy and polarity inversion.
We are using Altera alt_2p5g_phy with a fixed clock of 2.5Ghz. We need rx and tx polarity inversion in our set up. Unfortunately the GUI to set up the phy does not allow to modify the polarity. From the documents of the phy it is clear that this functionality is available. Is there a way to enable the inversion? Thanks in advance for any help.
Agilex 7 R-Tile PCIe Gen5: Avalon-ST DMA MWr TLP accepted by HIP but never received by Root Port
I am debugging a design using the Intel mSGDMA Read Master IP connected to the Intel Agilex 7 R-Tile PCIe Gen5 Hard IP through the Avalon-ST TX interface.The design uses the Intel mSGDMA Read Master to read data from memory. The Avalon-MM read data is then packetized into PCIe Memory Write (MWr) TLPs and transmitted through the R-Tile PCIe HIP. The transmit path is: Intel mSGDMA Read Master → dma_mwr_txc_gen → txc_mux_2to1 → pcie_bam_avst_intf → pcie_pio → Agilex 7 R-Tile PCIe HIP The endpoint enumerates correctly, the PCIe link trains successfully to Gen5 x16, configuration space accesses work correctly, BAR accesses work correctly, and normal MMIO/PIO operations function as expected. The only issue occurs when transmitting DMA-generated Memory Write TLPs. We have spent considerable time verifying the transmit path using both simulation and Signal Tap, and everything appears to be correct up to the HIP interface. Specifically, we have verified the following: The Avalon-ST TX interface follows the R-Tile User Guide. SOP/EOP placement is correct. Segment valid signals are correct. Header valid and payload valid are correct. ready remains asserted throughout the transfer. No Avalon-ST protocol violations are observed. The ACC signal gets asserted after the TLP is sent to the HIP The generated Memory Write header decodes correctly (128-byte MWr, correct addresses, requester ID, and length field). Payload contents are correct. Address increments correctly between successive packets. Signal Tap shows the expected TLP immediately before entering the HIP. The HIP accepts the packet (valid and ready handshake completes). No HIP or protocol error indications are observed. However, the Root Port never appears to receive the Memory Write TLP. The expected data never becomes visible to the host software, even though the packet appears to have been accepted by the HIP. After several DMA attempts, the Root Port—or sometimes the entire server—eventually becomes unresponsive and requires a reboot. We do not observe any AER messages, completion timeout messages, or other PCIe errors reported by the operating system. We also investigated timing closure to rule out timing-related corruption. At this point, we are trying to determine whether there is something beyond the Avalon-ST interface that could cause the HIP to silently discard or otherwise fail to transmit a posted Memory Write TLP. Has anyone encountered a similar issue on the Agilex R-Tile PCIe HIP where: the Avalon-ST interface appears completely correct, the HIP accepts the packet (ready/valid handshake completes), no protocol or PCIe errors are reported, but the Root Port never receives the posted Memory Write? Are there any additional HIP status registers, debug signals, credit counters, packet validation checks, alignment requirements, or other R-Tile-specific conditions that should be examined? Are there any known situations where a posted Memory Write can be silently drop after being accepted on the Avalon-ST interface? Any suggestions on additional debug points or known R-Tile HIP behaviors would be greatly appreciated. Thank you. Reza
