Does the 'remote update' block actually work on Cyclone V?

Ok, at least it isn't completely hosed.

Note that I'm not interested in how to write the EPCQ, I've got all that working nicely directly from a host application over PCIe to a custom Avalon slave that will bit-bang 8 nibbles for a 32bit transfer. Updates are dominated by the erase times (even allowing for the pedestrian speed of the reads for verify).

What I'm completely failing to do is get the fpga to reconfigure.

The remote update logic (there is a chunk of verilog accessed through a vhdl wrapper) is all present and seems to 'do things' in response to read and write requests (from signaltap), but the whole block seems to be connected to a black hole.

I can't get a sensible value read back from any parameter - I see all 1 bits for the width of the parameter.

So I always see 0xffffff for 'page select' and 0x1f for 'reconfig trigger conditions'.

Requests to reconfigure are ignored.

Thinks.... I wonder ...

In order to access the EPCQ pins we've enabled the 'JTAG to EPCQ' bridge (I've forgotten its proper name) that allows the JTAG interface be used to write the EPCQ while a user image is loaded.

I wonder if that has hijacked the 'remote update' logic so that the JTAG interface can request a reconfiguration?