Quartus 18.1 Soft LVDS transmitter w/ ext PLL core missing tx_outclock ddio generator logic?

Incidentally I've also uncovered a nuisance with the LVDS receiver IP (external PLL mode). My application requires a doubled clock so I have been forced to use the external pll option in order make use of the four remaining PLL outputs not used by my two LVDS Rx cores. The nuisance makes it impossible to be sure if the data out latency will match between two identical instances using separate input clocks. The input clocks are defined identically in the .sdc file. Call them ch0 and ch1. The pre-synthesis RTL simulates fine and matched ch0/ch1 test bench input data is still synchronized after deserialization, but simulating the .vo version of the project after synthesis and fitting, the ch1 data output is then one output clock behind ch0. So frustrating. I can only guess that synthesis is adding a pipeline delay to ch1 for routing purposes but there aren't enough megafunction knobs to insure that the pipeline of reciever0 matches the pipeline of receiver1. The fact that it doesn't match pre-synthesis RTL is troubling but I could live with it if I could simply guarantee synchronous output data.

Why two separate receivers instead of an 8 lane link? Because I don't have a guarantee that the serdes clock of ch0 is well enough matched to ch1 to use the ch0 clock to decode ch1 serialized data. I do know that after deserialization they are well enough matched that I can process them syncronously at the output bus of the LVDS receivers.

I further attempted to use internal LVDS Receiver/Transmitter PLLs and selected the box to "Use common PLL(s) for receivers and transmitters", ran the rx_inclock0 from ch0 to both the receiver and a subsequent transmitter, instantiated the ch1 receiver with rx_inclock1. RTL simulation works fine but basically simulates three independent PLLs whereas synthesis needs to figure out how to share PLL0 such that only 2 PLLs are utilized. I couldn't figure out how to make it work correctly and it always synthesized away my transmitter with the warning that it's outputs were stuck at ground so clearly it didn't connect a clock source in synthesis.

I now have a mostly working, post-fitted RTL simulation working with two 28:4 serdes receivers and one 28:4 serdes transmitter instantiated with external PLLs plus some core logic that requires 2x the frequency of the receiver clock (hence the need for access to the unused PLL outputs) but I still have to wait until I have hardware before I can figure out if the mismatch in the receiver pipeline latency really is mismatched or not.