Stratix III Remote Update

[Altera_Forum]

Hi all, 

for a Stratix III design I'm trying to choose an embedded reconfiguration scheme.   Ideally I want to select a scheme where I can update the configuration device via a serial port without an additional external controller.   The Remote Update does seem to tick all the boxes but at the cost of added complexity to implement.   chapter 12. remote system upgrades with stratix iii devices shows a Nios or user designed logic oversee the reconfiguration process:   1. Is there a design example using the Nios for a SIII remote update scheme (with MCU code etc.)?   2. Is there an alternative controller function available for the SIII for Remote Update?   3. Being a novice - is the Nios its compilation tools free?    4. The Serial FLASH loader would need an external controller to program the SFL image into the FPGA before programming the configuration device with new configuration data.  The Parallel FLASH Loader megafunction seems to connect to the CPLDs JTAG port - I'd need an external controller to clock data into this port. Please suggest any arrangement that I may not have considered that wouldn't need an external controller.   Thanks.

[Altera_Forum]

Stephen, 

So from what you are describing it sounds like you are wanting to use the Active Serial configuration scheme. You will have no external controller that configures the FPGA passively. Is this correct?  Jake

[Altera_Forum]

Hi again Jake, 

For the SIII device - in Chapter 11 Configuring SIII Devices doc table 11-2 (Note1) and table 11-3 show Fast AS as the only method available under the Remote System Update scheme, so yes with this arrangement I wouldn't need an external controller (which is what I want).   I read the thread you contributed to here:http://www.alteraforum.com/forum/showthread.php?t=5280&highlight=remote+upgrade+stratix+iii   The Remote Update Scheme seems to allow the overall hardware and functionality that I would like but I don't want to use a Nios processor - is it relatively easy to have a state machine take the place of the Nios - I see an example (not yours Jake, another one. I think yours may use Nios but I could be wrong) in the shared material section but I havn't looked at it yet.   stephen

[Altera_Forum]

Let me break this into two parts. I've used three methods for remotely updating FPGAs in the past: 

 1 - Use a configuration PROM which can be loaded via JTAG. This implies you have some JTAG controller in your remote system. Also, these PROM devices are not very large so really the don't accomodate Stratix III. This is passive serial or passive parallel mode.  2 - Use a CPLD in conjunction with a flash device. The CPLD handles reconfiguration of the FPGA (reads data from flash and programs FPGA). The FPGA is only responsible for requesting a reconfig from the CPLD. This mode is passive serial or passive parallel.  3 - Use a serial flash device and operate under Active Serial mode. This requires the FPGA itself to trigger and manage configurations. The only mechanism for doing this is with the Remote Update Controller as you stated.  To answer your question ... yes the remote update controller is easy enough to interface to that you could write some simple verilog or VHDL code to control it.   Now here is the second part:  How are you going to download a new FPGA image into the flash? This has nothing to do with the remote update controller. You need some way to write to the flash device. You have to answer this question no matter what configuration scheme you choose. I have done it three ways: a - Wrote a verilog parallel flash controller to write data into the flash. The data was transferred to the board via USB. In this situation we were using a CPLD to program the FPGA from the flash in passive parallel mode. b - Used a NIOS processor to write data into the parallel flash. Again using a CPLD to configure the FPGA. Here we transferred new configuration to the data via Ethernet. c - Used a NIOS processor to write data into the EPCS serial flash device. Here we used Active Serial configuration mode in conjunction with the remote update controller. I've used both USB and Ethernet to transfer configuration data to the board under this scheme.   In SoPC builder, Altera provides an EPCS controller peripheral that can be used to interface to the flash. Now for everything I've done with it, I've used the NIOS processor. But you wouldn't have to. You could certainly write a little controller to manipulate that EPCS peripheral to program your data into the flash and not use a NIOS at all. Also, Altera provides the ALTASMI_PARALLEL megafunction for programming the EPCS device. Those are the two directions I would point you in. http://www.altera.com/literature/ug/mfug_asmi.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=altasmi_parallel   You can certainly do everything you need to do without a NIOS. Now when it comes to the NIOS, I'm a big proponent. You'll never get so much use out of so few logic resources as you will out of an embedded processor. I believe the price tag on the NIOS is $500.00. However, I'd just twist your sales rep's arm until he gives it to you for free.

[Altera_Forum]

Thanks for your very complete answer - very much apprecated. 

 Does the Nios kit include compiler etc. (which one GCC ?)       Stephen

[Altera_Forum]

The NIOS Embedded Design Suite comes with an IDE (Eclipse) and it uses the GNU tool chain (so yes GCC compiler). You can install the Embedded Design Suite and start using it without buying the NIOS processor. You can also use the NIOS processor in OpenCore Eval mode if you wish. 

 Jake

[Altera_Forum]

Hi again Jake and all, 

final questions:   I understand the the Remote Update scheme deals with selecting and reconfiguring the FPGA from different images/areas of the EPCS serial device. It's up to my design to look after recieving updates from my (remote) host and programming them into the EPCS   1. I'm assuming that both my Factory/fall-back image AND any application image I have will need to have the necessary functionally to recieve incoming data and program this data to the EPCS   2. Is there any foolproof mechanism to ensure that I don't inadvertently corrupt the Factory image and create a lockout situation (where the only remedy is to get the Byteblaster out)?   Many thanks, Stephen       

[Altera_Forum]

1 - Correct. 

2 - Not really. Some flash devices have the ability to lock certain flash blocks but the EPCS devices do not support this. You don't really need to worry about the flash getting corrupted itself. The only risk is if your program mistakenly overwrites the factory image which you should be able to control to a reasonable extent.  Jake

[Altera_Forum]

Thanks again Jake for taking the time to reply, 

 Stephen.

[Altera_Forum]

Hi, 

   My name is Eldad Fragon, and I need to write a controller that will reside inside my FPGA, and upon triggeriing from an outsdie controller card will receive the bytes of the a new configuration file, and I would like to write those bytes to a paralle CFI flash(remote update function). The external controller card receives the new configuration file via a TCP/ IP protocol from an extrnal site. My FPGA is a Cyclone III device and I work in an active parallel mode to program the CFI Flash device. Is that controller doing what I described, and if can you guide me how to write this controllert that you wrote?  I'd appreciate very much any information you may provide.     Sincerely, Eldad Fargon efargon@yahoo.com

[Altera_Forum]

Hi, 

   My name is Eldad Fragon, and I need to write a user-logic that will reside inside my FPGA, and upon triggering from an outsdie controller card will receive the bytes of the a new configuration file, and I would like to write those bytes to a paralle CFI flash(remote update function). The external controller card receives the new configuration file via a TCP/ IP protocol from an extrnal site. My FPGA is a Cyclone III device and I work in an active parallel mode to program the CFI Flash device. Is that controller doing what I described, and if can you guide me how to write this controllert that you wrote?  I'd appreciate very much any information you may provide.      Sincerely, Eldad Fargon efargon@yahoo.com

[Altera_Forum]

--- Quote Start ---  Let me break this into two parts. I've used three methods for remotely updating FPGAs in the past:   1 - Use a configuration PROM which can be loaded via JTAG. This implies you have some JTAG controller in your remote system. Also, these PROM devices are not very large so really the don't accomodate Stratix III. This is passive serial or passive parallel mode.   2 - Use a CPLD in conjunction with a flash device. The CPLD handles reconfiguration of the FPGA (reads data from flash and programs FPGA). The FPGA is only responsible for requesting a reconfig from the CPLD. This mode is passive serial or passive parallel.   3 - Use a serial flash device and operate under Active Serial mode. This requires the FPGA itself to trigger and manage configurations. The only mechanism for doing this is with the Remote Update Controller as you stated.   To answer your question ... yes the remote update controller is easy enough to interface to that you could write some simple verilog or VHDL code to control it.    Now here is the second part: How are you going to download a new FPGA image into the flash? This has nothing to do with the remote update controller. You need some way to write to the flash device. You have to answer this question no matter what configuration scheme you choose. I have done it three ways: a - Wrote a verilog parallel flash controller to write data into the flash. The data was transferred to the board via USB. In this situation we were using a CPLD to program the FPGA from the flash in passive parallel mode. b - Used a NIOS processor to write data into the parallel flash. Again using a CPLD to configure the FPGA. Here we transferred new configuration to the data via Ethernet. c - Used a NIOS processor to write data into the EPCS serial flash device. Here we used Active Serial configuration mode in conjunction with the remote update controller. I've used both USB and Ethernet to transfer configuration data to the board under this scheme.   In SoPC builder, Altera provides an EPCS controller peripheral that can be used to interface to the flash. Now for everything I've done with it, I've used the NIOS processor. But you wouldn't have to. You could certainly write a little controller to manipulate that EPCS peripheral to program your data into the flash and not use a NIOS at all. Also, Altera provides the ALTASMI_PARALLEL megafunction for programming the EPCS device. Those are the two directions I would point you in. http://www.altera.com/literature/ug/mfug_asmi.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=altasmi_parallel   You can certainly do everything you need to do without a NIOS. Now when it comes to the NIOS, I'm a big proponent. You'll never get so much use out of so few logic resources as you will out of an embedded processor. I believe the price tag on the NIOS is $500.00. However, I'd just twist your sales rep's arm until he gives it to you for free.  --- Quote End ---       Hi Jake,   As a fellow work collegue of Stephen, I am currently about to implementing the REMOTE_UPDATE in conjunction with the ALTASMI_PARALLEL megafunctions to program the ECPS device in AS mode.   I only need to have a factory and one application image stored on the device.   I plan to write some user logic in the factory image that allows me to load the application image on power-up.  If the application image fails and a reconfig error automatically loads the factory image again, I need to interrogate the reconfig error in factory mode to decide whether to attempt to reload the same application image.   What then happens if the factory image endlessly tries to load the same application image and is stuck in a continous loop reloading itself back to the factory image.   Is it possible for me to create a factory image that : 1/ reads the status reg on power-up 2/ If an reconfig error had occured, increment an "reconfig error count" byte and write it to the General purpose memory area in the ECPS device.  3/ Perform a reconfig of the application image 4/ If this has failed, steps 1-3 will be repeated until I have reached my own hardcoded error count threshold. 5/ When the number of reconfiguration retries have been reached, the factory logic will just sit in factory mode and wait until new application image is loaded by an external host into the ECPS device.   This method involves me reading a byte from the ECPS device every time I am put into factory mode. The byte will store the error count and will bebe incremented every tiem an unsuccessfull reconfig has occured. Since I am not using a NIOS controller, is it still possible for me to access the General Purpose Memory Locations in an ECPS device using the ALTASMI_PARALLEL megafunction?   Many thanks,   Julie

[Altera_Forum]

I personally have not used the ALTASMI_PARALLEL megafunction so I may not be very useful there. However, what you have described seems very feasible to me and I don't see any problem with doing so. That is the purpose of the ALTASMI_PARALLEL megafunction after all is to allow you access to that memory. 

 I would ask however why you feel you need to try to load the application image more than once? My approach has always been that if it failed once, something is wrong and there is no reason to attempt to load it again until a new image has been loaded. You don't need to keep a count in order to do this. The status registers in the ALTREMOTE_UPDATE megacore will give you sufficient information to know that the application image failed. At which point you just sit and wait until your told through some external mechanism to try again.  Jake

[Altera_Forum]

Thanks for the speedy response Jake. 

 The reason I was thinking about re-loading the application image more than once was because I wanted my hardware to power-up into the application image and operate stand-alone initially without the need for my external software host.   It would be up to the fpga factory logic to determine whether to retry an application image reload, should this fail. Eventually when the software host communicates to the hardware, it will interrogate the fpga to determine if it is in factory/application and if it is still in factory mode, the host will attempt to reload a new application image to the serial device.    I suppose this may be overkill for the fpga to attempt to reload the application image a few times but I'm not sure what the statistics of reconfiguration errors are and whether an reconfig error is interpreted as a temporary or permanent failure of a serial device.   If its a temporary failure, then it warrants trying to reload the app image again. If its a permanent failure, then maybe waiting for external host is enough?   Cheers,   Julie

[Altera_Forum]

Julie, 

Typically, I never see configuration errors unless there is a legitimate problem with the bitstream. However, that may not be the case for your board. If you do feel you need to retry configuration several times then using I think the approach you've proposed is legitimate. You may also wish to use a simple eeprom or even an address in off-chip sram (that remains powered of course) instead if you've got such available just because the interface may be easier.  Jake

[Altera_Forum]

Many thanks. I'll give it a go, see if it works and let you know. 

 Cheers,   Julie

[Altera_Forum]

Hi, 

   I'm using a Cyclone III device to burn P33 parallel flash in AP mode. I'm trying to operate the remote-update to re-configure the FPGA from a new-burned configuration file I'm sending to the Flash. I wrote a simple verilog-based controller to take the new configuration from the external card and burn it to the Flash. Now I'm trying to operate the reference design, described in AN521. I'm trying to put the factory in address 0x20000, the "gold" application in address 0xE0000 and the second application in address 0x1A0000. The later will be the one the FPGA will use in everyday, and the first app will be the proof one, that in case of error it will go to app no. 1 Through a local bus I select which app I want to jump to, but from some reason I always jump to number 2!, though I always give them the right address. The address I read upon returning the factory app is always 0. What could be the problem? Does this have to do with the read_source parameter? How does this parameter work? Altera's app note are a little confusing.       Regards, Eldad Fargon