PCIe Hard IP returning stale data for Cyclone IV

I have recently ported a PCIe endpoint design working on Arria V to Cyclone IV , ( Transciever Starter Kit ) .

I need to go back but don't believe I see the problem on Arria V which is a very similar FPGA configuration.
PCIe, IMEM, NIOS II , JTAG_UART. For Cyclone IV I enabled the SSRAM since there isn't enough IMEM to
fit even a small application in a "free standing" environment.

Anyhow, BAR1 references IMEM.
NIOS sets a status word in IMEM to 0x5555AAAA and the RC is polling the status word via BAR1 reads.
When the RC gets a the read completion indicating the status is 0x5555AAAA, it issues a write to the
status word of 0x00000000 then polls the status word to make sure the status was reset.

The problem I see on the PCIe link is that the polling of the status word by the RC after the write of 0x00000000
still returns the original data 0x5555AAAA. I am thinking the only way this can occur is if the write of 0x00000000
on the Avalon MM interconnect is posted and "somehow" delayed while the polling reads after the write somehow
make it through to the IMEM.

Has anyone seen anything like this ? Do I have some issue at the Avalon MM interconnect ? I could add
SignalTap to examine the BAR1 master writes and reads. I could take the NIOS II out of the design and
see if I have the same issue just with IMEM and PCIe Hard IP. I have heard that if NIOS II and PCIe are
sharing access to IMEM, then it may need to be dual ported to keep everything balanced and not have
a given master locked out.

Thanks , Bob.

PS: I can't think of anything else that would be accessing the IMEM .