Bus LVDS on Arria 10 with Hardware Deserialiser

I'm trying to implement Bus-LVDS to communicate between a Cyclone IV and an Arria 10 device. For the Cyclone IV, I use the altlvds cores which are software serialisers, so no issue there.

For the Arria 10 device, there is no software SERDES IP available from Intel. Because the differential IO buffers don't support output enables, I've had to implement a software serialiser for transmit, using a combination of a DDIO block, and an Psuedo-Differential transmit buffer, with SSTL1.8V II as the IO standard.

For receive I would like to use the hardware DPA derialiser block to improve the receive timing margins. For this I am using an instance of the altera_lvds core. When the receive LVDS core is used alone, everything works fine. However if I try and connect the same pad to the Psuedo-Diff transmitter, Quartus will get part way through the fitting stage and then pop up with a window saying "Quartus Crashed" with the following message:

Problem Details
Error:
Internal Error: Sub-system: U2B2_CDB, File: /quartus/db/u2b2/u2b2_nf_io48tile_config_creator_module.cpp, Line: 10552
An io_lvdsio_buf_x2 cannot connect an to IO_SERDES_DPA if it connects to an additional primitives
Processors in use: 2
Stack Trace:
   0x12ca01: U2B2_NF_IO48TILE_CONFIG_CREATOR_MODULE::populate_iobuf_children_hierarchy + 0xfd1 (db_u2b2_cdb)
   0x12af50: U2B2_NF_IO48TILE_CONFIG_CREATOR_MODULE::populate_config + 0x7c0 (db_u2b2_cdb)
    0xdeae4: u2b2_populate_config_fn + 0x174 (db_u2b2_core)
     0x4076: PUT_SPMD_JOB_VOID_PTR_IMPL::thread_loop + 0x146 (ccl_put)
     0x3f16: PUT_SPMD_JOB_VOID_PTR_IMPL::thread_fn + 0x46 (ccl_put)
    0x1484e: msg_thread_wrapper + 0x6e (CCL_MSG)
    0x18210: mem_thread_wrapper + 0x70 (ccl_mem)
     0x2854: thr_thread_begin + 0xa4 (ccl_thr)
    0x17343: BaseThreadInitThunk + 0x13 (KERNEL32)
    0x526b0: RtlUserThreadStart + 0x20 (ntdll)

End-trace

Executable: quartus
Comment:
None

System Information
Platform: windows64
OS name: Windows 10
OS version: 10.0

Quartus Prime Information
Address bits: 64
Version: 22.1std.2
Build: 922
Edition: Standard Edition

I'm trying to understand whether this is a hardware limitation, or a bug in the Quartus software.

If a bug in quartus, is there a workaround to implement this?

If a hardware limitation, can anyone elighten me as to why this would be - the receive and transmit are surely separate enties, just sharing the same IO pad.