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
Honored Contributor
