Partial Reconfiguration Controller (1.3) - unexpected behavior on AXI Lite programming interface
I have a design with DFX enabled and I am having an issue with the partial reconfiguration controller IP core. This core has an optional AXI Lite interface which allows a software accessible interface for setting up parameters for the reconfigurable modules and the partial bitstream which we have chosen to use. I started to have issues when working on the programming software when the system would hang when trying to access the PR controller address space. The software control for this design comes through VME interface which is converted to AXI transactions in the FPGA. When AXI commands were sent to the PR controller I noticed in the ILA I have been using to debug the interface that sometimes the PR controller would not respond and that lack of response left the VME bus logic hanging which would lock up the system.
Further investigation showed that the issue was happening when performing either a write command after a read, or a read command after a write. The software function that is used to access the registers in the FPGA is written such that when a register is written it then gets read back. The first command, the write, appears fine and the PRC responds correctly. However on the read which follows the PRC responds to the write channel and not the read channel. Similarly if I start with a read command then follow with a write, the read transaction is correct but the write command fails because the PRC responds on the read channel. If I do a series of only writes or only reads all of those are successful, it's only when switching from one kind of command to the other.
I have generated this core from the GUI with 2019.2. I ran a simulation on the PR controller core using the simulation netlist generated from the IP core synth run and discovered the same behavior. I have attached a screen shot of the simulation. The sequence starts with a couple of writes which both behave correctly. Next is a couple of reads. The first read is incorrect as the PR controller still responds to the write channel. The second read the response is corrected. Next is a sequence of write, read, write, read. The PR controller continues to reply on the read channel and never the write channel.
I know that this IP is going to be discontinued starting with 2020.2 and replaced with the DFX controller v1.0. We are planning to migrate to 2020.2 and will have to update the core with the new DFX controller. I can't tell if there is any functional difference or simply a name change to put all of PR features under the DFX label.