Remote Update of Cyclone 10

[BCrowell]

In my application I would like to have an application configuration that is normally used on every power cycle and a golden default configuration that is used only when the application config fails to load. This is intended to allow the application config to be revised and reloaded by an external uC into the config Flash. Based on my understanding of the documentation I should be able to assign my golden config as the factory at page 0 and my application at page 1. Then change the address register to point to the application start address. This will result in the power cycle loading the application config unless that config gets corrupted and then the golden (factory) config would be loaded. All the remote update examples indicate the address register needs to be updated from the factory config, but is there a way to change this setting just the once from the Quartus software or similar? I need it to permanently point to the application address.

Thanks for your help.

[FvM]

Hi,
Cyclone 10 remote upgrade logic is expecting that application image is started through factory image. Start address and parameters, e.g. watchdog are set in this step. Starting application image directly would probably prevent fallback to factory image in case of failure. What's against using the standard solution?

 

[BCrowell]

The standard solution just doesn't fit that nicely into my application. I just want the factory page to be a fallback golden configuration in case anything corrupts the reprogramming process of the application page. This will then still allow additional tries at programming the new application config data. If I have to load the factory config, then trigger another load of the application config, which if it failed would then cause a third configuration cycle to reload the factory config. This would take extra time to get to a point where the FPGA is operational. It also adds extra requirements on the factory config to trigger the application load and also determine if that failed previously and therefore shouldn't be loaded again. It all just makes it more convoluted and complex. I just need a simple system that loads my application at power on and falls back to the factory config if an error occurs. Is there not a way to do this without the baggage of the remote config as you describe above?

[BCrowell]

Should I take the silence on this thread to mean there is no way to accomplish the simpler option I an looking for and will have to load the factory config first then load the application?

Thanks

Brad

[Fakhrul]

Hi BCrowell,

Unfortunately, executing a direct switch from the application image to another application image (golden configuration) in the event of an error, without intermediate steps (such as going through the factory image), is not possible. This intentional design decision is made to bolster security and mitigate the risk of unauthorized access.

Regards,

Fakhrul

[BCrowell]

Fakhrul,

I am ok with my golden config being the factory image, I just want to directly load the application config and only load the factory config if that fails. It sounds like that can't be done and the system needs to load the factory config first before switching to the application config in order to properly fall back in the event of an error. I don't necessarily see the advantage of this process but I haven't used Intel/Altera FPGAs in many years, so I just may be missing something. Is there something that the factory config does that differentiates it from an application config besides initiating the loading of an application config?

Thanks

Brad

[Fakhrul]

Hi BCrowell,

The factory configuration initializes the FPGA into a known state, ensuring that all essential components are set up correctly. This is crucial for the reliable and safe operation of the FPGA. It helps prevent undefined behavior that might occur if the FPGA were to start with no configuration or an arbitrary state.

Regards,

Fakhrul

[BCrowell]

Fakhrul,

Can you expand on the details of what the factory config does to put the device in a known state? I guess I am wondering what I need to do in my factory config to ensure this occurs correctly? Also I wonder why the application config can't do the necessary things to ensure this proper state? If one is not using remote update, then there is only the application config in essence, so what ensures the device gets to a good state in this case? 

Thanks for your help,

Brad

[FvM]

Hi,
necessary initialization in factory image is only related to remote update core, e.g. start address of application image and watchdog settings.

I must confess that I never tried to operate Cyclone 10 remote update core in a different way than suggested by user manual. It is definitely presuming that initial boot and mode transitions go through factory mode. As far as I understand, the behaviour is defined in FPGA silicone. MAX10 is operating slightly different, allowing also direct boot into application mode.

[Fakhrul]

Hi BCrowell,

Please ignore my earlier comment. I consulted with my senior, who is an expert in RSU, and it turns out you can load the application configuration directly and only resort to loading the factory configuration if error occurs. This is known as "Direct to Application" (DTA). For more detailed information about DTA, please refer to pages 6-7 in the Remote Update Intel® FPGA IP User Guide : https://cdrdv2.intel.com/v1/dl/getContent/794025?fileName=ug_altremote-683695-794025.pdf

Regards,

Fakhrul

[FvM]

I see "DTA" mode provided only for Arria 10/Cyclone 10 GX, not Cyclone 10LP.

[BCrowell]

I agree with FvM as it appears Direct to Application is not included for Cyclone 10 LP. In my Cyclone 10 LP project however I can select that option to have the device auto restart after an error. Not sure that it means it will do it though. Also, in direct to application mode how does the address register get set in the remote update IP core?

[Fakhrul]

Hi BCrowell,

Regarding the address register, you may refer to this Cyclone 10 LP Remote System Upgrade Design Example User Guide. The mentioned design example can be found here: Intel® Cyclone® 10 LP FPGA – Remote System Update Design Example

Regards,

Fakhrul

[BCrowell]

Fakhrul,

Yes, that is the example I am trying to simulate. I reviewed the user manual already and downloaded the design files. When I put together the simulation for these files and extended it to read the data from the update core though I get the X's when the registers are read back. 

Brad

[Fakhrul]

Hi BCrowell,

Could you share the message error ID or provide the screenshot of it perhaps?

Regards,

Fakhrul

[BCrowell]

I think this thread has strayed a bit from my original question. What I want to do is have the Cyclone power on and use the application config unless there is an error and then it would use the factory config as a default. But I don't know if this is possible and how I set the remote config address register in this case. The main question posed from my original post  is:

...

"All the remote update examples indicate the address register needs to be updated from the factory config, but is there a way to change this setting just the once from the Quartus software or similar? I need it to permanently point to the application address."

...

Thanks

Brad

[Fakhrul]

Hi BCrowell,

After checking with the internal team, I wanted to inform you that C10 LP doesn't support DTA mode (Direct to Application). DTA is a new feature exclusive to A10 and C10 GX only. Even in the RSU user guide, the DTA mode is explained under the A10 and C10 GX chapters.

Additionally, for A10 and C10 GX, there is an option for the boot address. However, C10 LP does not have it.

Regards,

Fakhrul

[BCrowell]

Fakhrul,

Thanks for getting the definitive answer on this question. It would be great if DTA mode could be extended to all Intel FPGA devices as it has the best fit for our applications. We can make do with the remote update as is though. 

Brad

[Fakhrul]

Hi Brad,

Thanks for your understanding. I agree with you that it would be great if DTA mode could be extended to all Intel FPGA devices, and I will definitely share this feedback internally.

I now transition this thread to community support. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get support from Intel experts. Otherwise, the community users will continue to help you on this thread.

Thank you for your patience and participation in the community.

Best regards,

Fakhrul