Agilex F-Tile tx_ready fails to assert

Did a whole lot more reading about the F-Tile clocking architecture, and I'm convinced that my inexperience/ignorance of F-Tile internals has contributed to some of this. Here's a visual clue:

I had followed the instructions and the tutorials and the demo-designs, but none of them were really clear about the SystemPLL requirements. When you choose the 1-instance 4-channel configuration, you are required to use a SystemPLL. That's about all the information Quartus provides. It makes sense that one PMA channel can't drive the clock tree of other PMA channels because there isn't an internal routing resource (according to the F-Tile User Guide.) However you can (and MUST) use the SystemPLL in the multi-channel configuration, because the SystemPLL DOES have a distribution capability.

Here's the rub. When I changed to the 1x4 configuration, Platform Designer complained that the "PMA Clocking" selection was invalid. So I changed that option to "SystemPLL," which resulted in an error message that "sys_PLL_clk_link" needed to be connected to ... something. I found a radio button in the F-Tile RefClk generator IP that enabled the SystemPLL link, and connected that to the F-Tile instance. Then Platform Designer complained that the two SystemPLL rates didn't match between those two blocks. Here's where my inexperience kicks in - I just made the rates match to clear the error message. The rate I chose was 805.6640625 MHz because that's what the clock generator block defaulted to.

It didn't occur to me that Quartus would accept that rate and compile just fine. I expected that Platform Designer, which has any number of configuration validations, would confirm that the input clock rate and the output clock rate of the "everything is bypassed" transmitter configuration would be sane. Nope.

In my application, the output PMA serializer is running at 1562.5 MHz (10x the 156.25MHz ref clock.) I chose a 20-bit data path width, which says the PMA word clock is 78.125MHz. Because every element in the Tx path is just pass-thru, there's no rate adaptation. The clocking, whether it's PMA or SystemPLL, had better be 78.125MHz at every stage in the path. Otherwise, you'll see FIFO empty or full flags bashing around in what should be a synchronous flow-thru system. I did observe the FIFO flags doing weird things when they shouldn't, and I'm pretty sure the clock rate mismatch is responsible for that. There's still some F-Tile configuration weirdness going on because I have observed the tx_clkout signal, and it was nominally 78.125MHz and not 40.283 (which would have been 805.6640625 / 20). I'm not sure what clock was being provided to me on the tx_clkout pin from the core. Maybe I was getting the PMA clock but the F-Tile was using the SystemPLL clock for some of the internal bits? I don't have any visibility into those elements.

I have configured the SystemPLL to be 78.125MHz and ... still no output. Tx_Ready still doesn't assert.