Occasional ContributorAgilex F-Tile tx_ready fails to assert
I'm starting a new thread, because the previous discussion was booted into the void:
I have an 027 SoC evm with the AGIB027R31B1V1VAA part installed. I removed the heatsink and verified this.
I have two implementations of a soooper-simple design that attempts to drive fixed patters out the FGT transceivers. One implementation works, the other does not. Both designs use a common top-level Verilog file (with minor accommodations for the core-interface signal variances.) The end goal is to drive signals at 1.5Gbps out the four lanes in one of the QSFP-DD cages present on the EVM. (There's a bus-twist issue in the pin assignments, but I will address that in a different posting.)
So, the working design uses Platform Designer to install the HSSI refclk generator, and connects that to four instances of a x1 PMA core. (source files attached) Outputs are pretty much what you'd expect.
The reference clock on the board is 156.25MHz, and the core is configured for an FGT output, Simplex TX, NRZ line coding, and a bit rate of 1562.5 MHz (10x the ref clock.) The F-Tile PLL is running in integer mode. The AIB data interface is set to 20-bits width, and I'm providing a fixed 20-bit pattern on each output - validated by the 78.125-ish MHz measurement in the bottom-right corner of the scope screengrab. PMA config is mostly the default values - Elastic FIFO for the PMA FIFO; the other two are Phase Comp. Interface is single rate, with the Core FIFO partial-full threshold dropped to "5" to clear the attendant error.
Where this goes to hell is when I change from four-instances of x1 lanes to one-instance of x4 lanes ... which should be a perfectly valid configuration, right? Same design, same clocking structure, same top-level Verilog, same physical hardware platform. All I asked for was a 4-channel binder group in Platform Designer (which presumably coordinates operation of the channels as a group.)
I brought all the status and FIFO semaphores up to the top level at one point, and "tx_ready" is not asserting in the one-instance x4 case. None of the four tx_ready lines asserts. Ever. Now before you ask, yes, there's a reset-release block in Platform Designer, and there's a state machine at the top level Verilog that enforces the reset-request behavior at power-on per the F-Tile PMA documentation.
I have poured through the littany of warning messages produced by the compile process, and the one-instance design generates this gem that caught my attention:
Warning(16735): Verilog HDL warning at directphy_f_sip_460_p4taocq.sv(781): actual bit length 4 differs from formal bit length 1 for port "dphy_reset_status_tx_ready_i"
So there appears to be a width-mismatch in the core generation script when the "Number of PMA Lanes" parameter is something other than 1. I dug further into the directphy_f_sip_460_p4taocq.sv source and found this not-confidence-inspiring comment:
// Soft reset controller: // Replaced the parameter l_sys_xcvrs with num_xcvr_per_sys*num_sys_cop to make it more explicit that the soft reset controller operates // on each transceiver lane in a system copy, or reset group, but each reset group is tied to a single system copy // The number of ports is unchanged. The ports with the '__MB__ markup are not brought out to the top level in the IP, but are // connected at the qtlg step using cross-module references. // TX outputs are present only if the tx is enabled
It makes sense that the Soft Reset Controller would try to resolve all the individual tx_ready signals for a group before letting the group run. And it makes sense that the tx_ready width-mismatch might make the compiler shrug its shoulders and just insert the default GND for the signals it can't explicitly map. And it would make sense that this is being caused by a script-hack that [poorly] implements cross-module referencing rather than using the hierarchy properly.
I'm convinced that Quartus has a problem implementing the F-Tile PMA core properly for anything other than the demo designs. I'm running 23.3, but have experienced this issue with 23.1, and 22.3 is completely non-functional with the F-Tile PMA core.
Archive is attached with screenshots, verilog, and .qsf files. I did not include anything else, because you'll need to re-implement the Platform Designer stuff for your particular version of Quartus, and the design is simple enough that it's not an imposition to clean-sheet this from scratch with the included info as a guide.
If you want me to dig further into this, I have a "fix other peoples' problems" rate of $250/hr with a 4-hour minimum. But you're more than welcome to fix it yourselves.
