Max10 Soft LVDS bit slip shouldn't be needed for odd serialization factors. How to shift bits with external pll mode using nothing but compile time phase adjustments?

Note that my system is attempting to receive channel link data if that was not clear from the first post. The serialized bit alignment defined by channel link causes the word transition boundary to be centered in the high time of tx clock period (2/7 T) within the assymetric 57% duty cycle LVDS Tx clock. After some experimentation in simulation I realize had previously adjusted the LVDS Tx stimulus to make the Rx data correct rather than making the input word transition occur in the correct location vs. channel link. With that test bench correction I found a solution in code that works around what I consider a short-coming of the Soft LVDS megafunction (the ability to set the word boundary relative to clock phase especially for odd serialization factors where phase alignment is completely deterministic and does not require a training pattern) by merely pulsing the rx_data_align input the desired number of times after PLL lock goes high. It seems like the default Soft LVDS megafuction configuration uses bit-slip = 0 which I assume implies that the word boundary in the serial stream is edge aligned to the rising clock edge which is not the same place as a channel link 1 interface. I get that for even serialization factors there is ambiguity between the rx clock and the word boundary in the serial stream and a training pattern must be used to establish the channel. What I'm wondering now is for an odd serialization factor will the word alignment always come up correctly due to the 57% duty cycle clock??? If so, a simple counter to fire off my N-2 "rx_data_align" pulses after the external PLL locks seems to get the channel setup correctly in simulation but I question how reliably this will power up over may power cycles... the alignment in the Soft LVDS IP is based on DDIO captures to allow the internal serialization clock to be cut in half (which is what makes it work on larger process nodes to begin with) but this adds to the aligment ambiguity. Any feedback from Intel on this would be helpful.