Agilex F-Tile bus reversal / twist

Ah, the hotkey <F3> canned response. But I'll provide more info because you asked me to, all sweet like.

The design is about as brain-dead as it gets - define a TX Simplex output in Platform Designer, then blast static pattern data out using the provided clocks (which are derivative from the 156.25 FGT reference oscillator connected to this F-Tile externally.)

At the top level, instantiate the Platform Designer primitive, then map those HSSI signals to the attendant pins (use Pin Planner if you're a masochist, or just edit the ASCII text in the .qsf file directly.)

#
# Socket 0
set_location_assignment PIN_R14 -to clk_13c_fgt_refclk4_p
set_instance_assignment -name IO_STANDARD CML -to clk_13c_fgt_refclk4_p -entity top
set_location_assignment PIN_AC10 -to qsfpdd0_tx3
set_location_assignment PIN_Y7 -to qsfpdd0_tx2
set_location_assignment PIN_W10 -to qsfpdd0_tx1
set_location_assignment PIN_T7 -to qsfpdd0_tx0

You'll note that these pin assignments match those highlighted in the original post. Smack the "compile" button and let 'er rip!

The system will fault when trying to place the HSSI signals on pins:

Here's the error transcript with some high-tech "word wrap" enabled:

Error(22144): Cannot place the block u0|directphy_f_0|directphy_f_0|dphy_hip_inst|persystem[0].perxcvr[0].fgt.tx_ux.x_bb_f_ux_tx at location fgt_q2_ch0_tx because the connected cell u0|directphy_f_0|directphy_f_0|dphy_hip_inst|persystem[0].perehip_tx[0].tx_ehip.x_bb_f_ehip_tx|bb_f_ehip_tx_xcvr25g0 can only be placed in location(s) bb_f_ehip_tx_xcvr25g[0], bb_f_ehip_tx_xcvr25g[4], bb_f_ehip_tx_xcvr25g[8], bb_f_ehip_tx_xcvr25g[12], bb_f_ehip_tx_xcvr25g[16], bb_f_ehip_tx_xcvr25g[20]. 

Error: Design cannot be programmed onto available F-Tiles because given location constraints are conflicting, or because the design requires more resources compared to what is available on current device 

Amusingly, it's complaining that output[0] cannot be placed at location "ch[0]" because it can only be placed at locations [0], [4], [8], [12], [16], and [20]. If you edit the pin assignments to map output[0] -> ch[3] etc. (i.e. introduce the bus twist) it'll compile just fine. The top-level verilog maintains subordinate-entity continuity throughout - parallel data [0] maps to PD entity input [0], etc - but none of that really matters. The problem is the HSSI serial output connection to the physical pin.

.directphy_f_0_tx_serial_data_xcvr0_tx_serial_data     (qsfpdd0_tx0),     //  output,   width = 1,   		.directphy_f_0_tx_serial_data_xcvr1_tx_serial_data     (qsfpdd0_tx1),     //  output,   width = 1,
.directphy_f_0_tx_serial_data_xcvr2_tx_serial_data     (qsfpdd0_tx2),     //  output,   width = 1,
.directphy_f_0_tx_serial_data_xcvr3_tx_serial_data     (qsfpdd0_tx3),     //  output,   width = 1,

Top-level verilog and .qsf files are attached.

I look forward to being scraped-off to "community support" (hotkey <F5>) in short order!