Remote configuration using Cyclone IV

[Altera_Forum]

I want to boot cyclone iv fpga(slave in attachment) in remote AS configuration. 

As mentioned in the handbook the bootflash should contain factory image and application image. What does the factory image contain? (does it contain altremote_update megafunction and should it trigger application image?) Also does the application image contain the altremote_update along with altasmi_parallel megafunction? Detailed answer would be appreciated.:)

[Altera_Forum]

A detailed answer requires the post to contain plenty of detail.... 

 What hardware is this? What handbook are you referring to?  Regards, Alex

[Altera_Forum]

--- Quote Start ---  A detailed answer requires the post to contain plenty of detail....  What hardware is this? What handbook are you referring to?  Regards, Alex  --- Quote End ---    The configuration scheme thought of is as follows:  1. the master fpga boots itself from serial configuration device using active serial configuration receiving configuration data over serial interface. 2. usb, ethernet and uart controllers are instantiated in master fpga through which configuration data (of slave fpgas) is received and sent to the slave fpgas (incase of reconfiguration) through serial transceiver directly or indirectly through cfi flash. 3. when the slave fpga is first powered up in remote mode, it loads the factory configuration image located at page zero which corresponds to the start address 0x000000 in serial configuration device (epcs). 4. the factory configuration image writes the remote system upgrade control register to specify the address of the application configuration to be loaded. 5. when the fpga successfully loads the application configuration, it enters user mode. in user mode, the soft logic (the nios ii processor or state machine and the remote communication interface) assists in determining when a remote system update (through serial transceiver) is arriving. when a remote system update arrives, the soft logic receives the incoming data, writes it to the configuration memory device and triggers the device to load the factory configuration.  6. the factory configuration reads the remote system upgrade status register, determines the valid application configuration to load, writes the remote system upgrade control register accordingly, and starts.    I am referring to 'Configuring and Remote System upgrade - Cyclone IV' and 'AN603: Active Serial Remote System Upgrade Reference Design'.

[Altera_Forum]

I take it you're looking to design a system based on the app note. Note: AN603 discusses Aria and Stratix devices and not Cyclone IV. That aside... 

 The simple answer is that whichever designs (application or factory) that you wish to support the remote upgrade will need the blocks you mention. Depending on the requirements of your system you may only wish to be able to support remote upgrade from one of the images. However, if you wish your system to support remote upgrade whether it has booted to the application or the factory image, then both designs are going will require the logic.  Yes, the factory image must 'trigger' reconfiguration to the application image. At power up, the FPGA will only ever boot from the factory image before attempting to boot the application image.  Regards, Alex

[Altera_Forum]

Thanks Alex. 

Yes, I know the app note an603 discusses stratix and arria devices, but i believe its the same for cyclone as well. I want the remote configuration module to be instantiated in both the factory and application images since the remote upgrade might be arriving at any given time and should be able to change the application configuration data and trigger reconfiguration. Also application configuration image contains image update circuitry which fetches new image (from master controller in this case) and updates the content in the serial configuration boot flash. This image update circuitry cannot be in factory configuration image. Is this correct?

[Altera_Forum]

Yes, I agree with pretty much everything you're suggesting there. Except... 

  --- Quote Start ---  This image update circuitry cannot be in factory configuration image.  --- Quote End ---   Why not? I'd question why you would not want the factory image to be able to update the boot flash with a new application image.  Consider the case where an application image update fails. This may be due to image corruption or a power failure during the update. When the unit attempts to boot to the application image next time, it fails and defaults back to, or remains at, the factory - assuming that's what you set it up to do. If, from that state, you're unable to accept a new application image, where does that leave your hardware?  Regards, Alex

[Altera_Forum]

Thanks. 

So in that case, it would be better to have image update circuitry in both (factory and application) image files. Also, can we update the application image file through Serial Protocol(or any other interface)? The App note An603 as you rightly mentioned is limited to stratix and arria devices and 'AN521: Cyclone III Active Parallel Remote System Upgrade' mentions the update can be done through JTAG only.  Chinmay

[Altera_Forum]

The real problems start when you need to use PCIe. 

AS tends to be too slow to meet the PCIe reset timings, a 'double configuration' is almost bound to be too slow. CVP can be used (on some parts) to download most of the fpga image over PCIe, but it isn't at all clear to me that it is possible to build multiple images that can be loaded as alternatives - unless they are all built at the same time, or as a direct development sequence. In particular I can't imagine a support group being able to build a bug fix that can actually be loaded.  This means that any (non-TAG) field upgrade will not only need the actual image for the fpga, but any failure will require JTAG to fix.  With PS a jumper could be used to download a small (non CVP) factory image from a different part of the EPCS memory.

[Altera_Forum]

Chinmay, 

 Yes, I think it would be better to have the update circuitry in both images.  Upgrade over another interface? Why not. Cyclone IV supports IP (or your own code) to update an EPCS device attached to it's AS interface. So, there's nothing to stop you sourcing an image over whatever interface you chose and writing it to the EPCS.  I don't think there's any restriction forcing you to do so via JTAG. AN521 discusses using the PFL to program flash devices via JTAG, but doesn't suggest (I don't think) that that's the only way.  Regards, Alex

[Altera_Forum]

Hello! 

 I have the similar task. Please advise how to replace the content of EPCS4 by means of NIOSII? The AS configuration schematic on a custom board is as follows: http://www.alteraforum.com/forum/attachment.php?attachmentid=10117&stc=1  The original .jic file was programmed into EPCS4 in-factory via JTAG ( SFL ). To make in-field upgrade I plan to make NIOSII replace the original .jic file inside EPCS4 by a new one. After that replacement the next power-down/power-up cycle will load an upgraded version of .jic from EPCS4 into Cyclone IV. I know, that this approach has some drawbacks and risks, but I think it is the simplest to implement. Is there an Altera document, that describes how to make what I need? If not, then please advise how to make it.

[Altera_Forum]

Assuming your Nios has access to the EPCS, then you can simply use Nios to overwrite the contents of the EPCS from the base address - where the FPGA boots from. 

 However, you clearly need to be careful! Until you've completed the write you're clearly only 'corrupting' the FPGA's boot image. So, should it not complete successfully - a power failure/glitch - you'll end up rendering the unit useless, since the FPGA won't boot from the corrupted image, and without any means of recovering it.  You imply you're writing new code to do this which suggests your Nios doesn't boot from the EPCS. Is that right? If so your Nios may not have access to the EPCS anyway. This is determined by the peripherals around the Nios currently in the FPGA. Typically it would need an 'epcs_flash_controller', although this could be another, 3rd party, peripheral with access to the EPCS. Without this it may well not be possible.  Cheers, Alex