Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20638 Discussions

Remote System Update with Max 10 10M16

Altera_Forum
Honored Contributor II
3,124 Views

Hi, 

 

during the last days I have been trying to get Remote System Update working on my Max 10 device. I have been following the extensive design guide lines described in https://www.altera.com/en_us/pdfs/literature/an/an741.pdf

However I am still having problems getting the system to run, mainly because I am using the 10M16SAU169C8G device instead of the one used in the reference. (10M50 series) 

 

I was wondering how the different features effect the RSU. Does the smaller size still allow for RSU with Dual Configuration? I am getting "Error (14703): Invalid internal configuration mode for design with memory initialization" with the current design. 

 

What size should my On-Chip Memory be in the qsys-System? The design guideline is too big for my device, so I chose 30720 Bytes. This part is compiling without errors now, but I'm not sure if the size is big enough moving forward. (reference design uses 122880 bytes instead) 

 

 

I really appreciate any help, because I am stuck at the moment. 

 

Kind regards, 

Konrad 

 

edit: I am using Quartus 16.0.
0 Kudos
9 Replies
Altera_Forum
Honored Contributor II
766 Views

I've been looking at remote update as well, also for an Arria 10 (non-SoC) design. I have no interest in using a Nios or Qsys, however. I've found the documentation to be terrible so it's likely to be a trial and error affair on the dev kit. 

 

Here's the text of an email I sent to our local Altera distributor FAE. If anyone can comment on any of my questions/concerns it would be very much appreciated. 

 

-------- start of email ---------- 

I’m looking at remote system update again for our Arria 10 design. I find the Altera documentation on this woefully inadequate. The “Arria 10 Core Fabric and General Purpose I/Os Handbook” document covers remote update for Arria 10 in Chapter 7. The “Altera Remote Update IP Core User Guide” document duplicates a lot of the same content in the chapter for Arria 10. 

 

The documentation talks about “direct-to-application” and “application-to-application” update modes, but it gives no description of either. I’ve searched the Altera website for more information and there is none. In the 2016.06.13 version of the “Arria 10 Core Fabric and General Purpose I/Os Handbook” document there was a link on page 7-38 to a document titled “Direct-to-Application Design Considerations”, but the link was dead and has now been removed in the latest release of that document. 

 

I’ve looked at AN-603 but did not find it of much help. For one, it’s not for Arria 10 so some of it doesn’t apply to us. I don’t want to make a research project out of this. Charlie is in the schematic phase now so I need to get our remote update solution figured out soon so he can complete the schematic. 

 

There is an Arria 10 remote update project on rocketboards, but it’s for the SoC and therefore no doubt has a bunch of Linux crap in there that I don’t want to deal with. 

 

https://rocketboards.org/foswiki/view/projects/remotesystemupdate 

 

Statements like this in the “Arria 10 Core Fabric and General Purpose I/Os Handbook” give me some pause: 

 

• “If your design is sensitive to the PCIe boot-up requirement, Altera recommends that you do not use the direct-to-application feature.” (page 7-39) 

o Unfortunately, no description at all is give of the “application-to-application” mode. I assume it means always boot into the factory image to start and then reboot into the application image from there? 

• “Altera recommends that you set a fixed start address and never update the start address during user mode. You should only overwrite an existing application configuration image when you have a new application image. This is to avoid the factory configuration image to be erased unintentionally every time you update the start address.” (page 7-38) 

o WTF?? How about a little elaboration??? 

 

I’m getting very frustrated with this. I understand what needs to happen at a high level, but that doesn’t give me enough to confidently dive into an implementation. 

 

Here’s what I do know: 

 

• No Nios. I’ll implement the logic in state machines. 

• We’ll use a EPQC-L flash. 

• The solution has to be bulletproof. We can’t be bricking cameras out in the field under any circumstances. 

 

Our FPGA will be a PCIe endpoint and PCIe is the only path between the Processor and the FPGA. So the factory image at a minimum has to come up with PCIe operational so that new application images can be uploaded and written to flash. 

 

Can you point me to any additional documentation? The missing “Direct-to-Application Design Considerations” document would be great, even if it’s outdated. Any other recommendations? Do you have any customers doing remote update without a Nios? 

 

If it would be faster, maybe you could stop by next week and give us a detailed walkthrough of exactly how the different remote update modes work, advantages and disadvantages of each, risks with remote update, etc. We’re trying to avoid having to add an external processor on the sensor board to manage FPGA configuration and remote update, but I’m kind of thinking that an external processor would be the only truly bulletproof solution. 

-------- end of email -------- 

 

Apologies to the OP for hijacking his thread, but this seemed like a good opportunity to chime in with what I'm seeing for remote update. Hopefully any responses can help us both. 

 

Bob
0 Kudos
Altera_Forum
Honored Contributor II
766 Views
0 Kudos
Altera_Forum
Honored Contributor II
766 Views

@sstrell - 

 

Thanks for the links. No, I had not seen those. Wrong family but will probably help fill in some blanks for me. Those must be fairly new or I think I would have seen them before. 

 

Bob
0 Kudos
Altera_Forum
Honored Contributor II
766 Views

RSU is supported in all MAX 10 devices except the smallest (10M02 I think) and the flow is the same for all of them.

0 Kudos
Altera_Forum
Honored Contributor II
766 Views

I just realized that I misread the original post in this thread. I'm targeting Arria 10, not Max 10. But I think the remote upgrade procedure is very similar for all families that support it. Hopefully the OP and I will both get something out of the Max 10 remote upgrade training videos. Thanks again, sstrell.

0 Kudos
Altera_Forum
Honored Contributor II
766 Views

 

--- Quote Start ---  

I just realized that I misread the original post in this thread. I'm targeting Arria 10, not Max 10. But I think the remote upgrade procedure is very similar for all families that support it. Hopefully the OP and I will both get something out of the Max 10 remote upgrade training videos. Thanks again, sstrell. 

--- Quote End ---  

 

 

No, I think it's pretty different. MAX 10 has onboard flash memory that is used for all this. Arria 10 does not. Arria 10 supports partial reconfiguration, which MAX 10 does not. Maybe that's more what you're looking for.
0 Kudos
Altera_Forum
Honored Contributor II
766 Views

Hi,  

 

first of all thank you guys for your responses! Any help is appreciated. 

 

I had already finished out the online training but I still can't get my project design to work. 

 

The quartus compiler throws an error message because of invalid configuration mode, and I can't figure out why. 

In the quartus settings I have selected "Dual Compressed Images". I did the same thing in qsys for my On-Chip Flash, where I also followed the steps for the UFM/CDM configuration.
0 Kudos
Altera_Forum
Honored Contributor II
766 Views

Hello KonradH and Bob, 

 

Has anybody of you been able to successfully use Remote System Update block? 

 

Regards, 

Bhaumik
0 Kudos
MYild1
Beginner
766 Views

Hi Bhaumik,

I will ask the same question you asked before, did you used RSU succesfully?

0 Kudos
Reply