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

Yes, the Remote Update Block works fine in Quartus 14.1

I use the new Altera Serial Flash Loader whereby is much easier to handle Factory and Application images

for FPGA configuration and Nios firmware. AN-736 (2015.05.26) is strongly recommended!

My testsystem is a Cyclone 5 (5CEFA7) custom hardware with a EPCQ256 (Micron N25Q256A, x4 mode) serial flash device.

With QSYS I created a factory and an application design (ru_sopc.jpg). Within the systems are the Serial Flash Loader and the Remopte Update block.

For read and write parameters of the Remopte Update block I use an avalon slave (custom hardware). Factory and application design distinguish

in nios reset vector and system ID (not necessary). (reset_vect.jpg)

factory reset vector offset 0x410000

application reset vector offset 0x810000

Furthermore two nios eclipse projects whith different BSPs are needed. In the linker script tab of BSP editor you will see the appropriate reset addresses.

(offset is added to the base address of SFLs avl_mem). (ru_bsp.jpg)

In the factory project I set the start address for application image (writing 0x570000 to page select parameter at "100") and the AnF Bit to "1" (param "101")

Reconfiguration starts with '1' at reconfig input of Remote Update block. (refer Altera Remote Update IP Core User Guide, 2015.06.15)

The application project read the system ID and the reconfiguration trigger parameter to verify that the right image was booted.

Compile the projects and generate the .hex files with Make Targets -> Build -> mem_init_generate (refer AN-736).

After creating and fit/compile the projects a .jic file for programming the EPCQ is needed. With Quartus Convert Programming Files utility you can put

both images into one file. After adding the flash loader device (5CEFA7) you put the factory .sof in Page_0, start address 0x0 and add the factory .hex file

(<SFL-qsys-name>.hex). Create a new SOF page_1 at and choose the start address of application FPGA configuration, in my case 0x570000.

Then add the .hex file for application image. The resulting .map file is:

BLOCK START ADDRESS END ADDRESS

Page_0 0x00000000 0x0026CB73

epcs_controller.hex 0x00410000 0x00421F73

Page_1 0x00570000 0x007DB248

epcs_controller.hex 0x00810000 0x00821F0F

(jic_for_C5_remote.jpg)

After programming the .jic and powercycling the hardware I get following messages at my RS232 terminal:

Nios2 Factory Image with SYS ID 0xFF

Boot Status 0x0

AnF Bit 0x0

Reconfig Address 0x570000

Nios2 Application Image with SYS ID 0xAA

Boot Status 0x4

AnF Bit 0x1

First the factory image is loaded from EPCQ then reconfiguration with application image is done.

Best regards

Jens

DSL,

I have to usleep() before I can read back the page select parameter. Without sleep I read 0x0.

Jens

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?

I'm using remote update block in an embedded device wich is connected to a host PC via Gb-Ethernet. The EPCS contains the factory an application image for Hard- and Firmware.

Over Ethernet we can update both and trigger a reconfiguration. The access to the rsu block is realized by an avalon slave. The vhdl code is attached.

To get the RSU for Cyclone 5 running I used this Wiki:

http://www.alterawiki.com/wiki/remote_update_for_cyclone_v

Jens

Sorry, I'm using Serial Flash Controller (not the loader). So that was wrong in the Post above ...

Jens

I think the vhdl I have is much the same as that referred to by the wiki page.

Certainly my avalon slave does much the same as the referenced code.

I have a bit of nasty logic to divide the Avalon clock down by a factor of 4 (from 62.5MHz to just over 15) but I don't think that is causing grief.

(It uses the falling edge to generate a mask for the clock, so removes three of every 4 clock pulses.)

For the Serial Flash Controller, the RSU block and the Avalon slave I'm using 25 MHz. The rest of QSYS (including Nios2) is clocked by 100 MHz which are generated from the 25 via PLL.

Clock crossing logic is done by QSYS.

dsl, Were you able to resolve your issue here? I am having the exact same problem.

Edit: I was able to resolve the issue. You must make sure that the Device Configuration mode is set to 'Remote' in the Quartus II software. Doing so allows the Remote Update component to be read/written.