How does the Remote Update IP work?

Hi Nooraini,

Sorry about the screenshot, I forgot to explain that the Signal Tap only shows reading parameter 000 (reconfiguration trigger register). It does not show writing the parameters. As you explained, the first step is to check this register. This is where my problem lies. I am expecting to read 0 on PoR, but instead I am reading 0x1f.

As for providing screen shots for the signal tap for the reconfiguration, states 5'b00100 to 5'b01100 are for setting the reconfiguration application boot, wdt, and AnF bit, but Since I read a 0x1f from the reconfiguration trigger register it goes to 5'b11111 and does nothing there.

The reset_sequencer_0_reset_out0_reset is the reset going into the remote update ip block in Platform Designer.

Is there something wrong with my parameter read? It is similar to the example waveform given in the Remote Update IP Core User Guide, but I wait for the Busy signal to deassert before deasserting read_param whereas the example only asserts read_param for one clock cycle.

Thank you.

Hi SrLam9,

I have attached an example project design I just tested today on Arria 10 dev kit which works. You can refer to the rsu_cb.vhd which I wrote the parameters to read reconfiguration status register and write the AnF, disable watchdog timer and application image boot address. After power up the board (of course EPCQL was programmed with a .jic before), when I check using SignalTap to read the reconfiguration status register, I can observe the data_out[31..0] show 00000. You can try to check the rsu_cb.vhd and compare with yours.

Regards,

Nooraini

We have been trying to implement a similar solution in one of our projects and have observed the same problem. In our case, the FPGA is configured in DTA mode and we have a simple FSM that reads the Reconfiguration Trigger Conditions to determine what caused the reconfiguration. The FSM essential only has 3 states that are performed when reset is de-asserted:

1. Wait for the busy signal to be de-asserted

2. Wait for 4 clocks (inherited from an old design)

3. Read the Reconfiguration Trigger Conditions register

However, the register was always returning 0x1f, in the exact same way as described in this post. Eventually, we discovered that the IP requires some initialisation time after the busy signal is de-asserted for the first time. By waiting for 1ms after the busy signal goes low, we were able to read the register. The updated FSM still only has 3 states that are performed when reset is de-asserted:

1. Wait for the busy signal to be de-asserted

2. Wait for 1 ms

3. Read the Reconfiguration Trigger Conditions

It's worth pointing out that the 1ms figure was reached after trial and error, as this initialisation time isn't documented it's not clear how long the delay actually needs to be.

As this is an old post, I guess the original poster has solved this problem. However, this has proven to be a bit of a time sink for us so I'm posting this solution in case anyone else has this same issue.