Does aborting a partial FPGA reconfiguration possibly result in an undefined state?
<p>I'm working on a reconfiguration controller for a <a href="https://en.wikipedia.org/wiki/Reconfigurable_computing" rel="nofollow">reconfigurable</a> CPU. One of the features I tried to implement is to handle CRC errors properly, and also to allow for aborts during reconfiguration. I am using a Virtex7 board and as described in <a href="http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf" rel="nofollow">ug702.pdf (page 98)</a> reloading a bitstream after a CRC error isn't a problem, also an ABORT can be performed as shown in <a href="http://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf" rel="nofollow">ug470_7Series_Config.pdf (page 48)</a>.</p>

<p>At first glance it seems to work as described in the documentation, that is on a CRC error my reconfiguration controller notifies the CPU and the CPU gives my controller a fresh bitstream. Also, the CPU can send my controller an abort command and the controller would abort it as described in the docs. </p>

<p>Hovewer, it seems to work only sporadically, sometimes the whole system freezes, sometimes I get nonsensical exceptions, and sometimes unconditional jumps are not taken it seems. </p>

<p>I am not sure whether I messed up somewhere or this was to be expected, since the containers where the partial bitstreams go to are interconnected with the pipeline and the bus. I remember to have read in some xilinx pdf that the bitstream is not finally configured until the desynch command at the end of the bitstream was encountered. Does that mean the fabric is not affected until the full partial bitstream is loaded onto the fabric, without any errors, and therefore couldn't affect the rest of the design. Or is a partially loaded partial bitstream actually configured onto the fpga and can trigger all sorts of weird signals on its output ?</p>