Hi, I am trying to understand how to implement a Remote System Upgrade in our flow to allow remote upgrade. Currently our MAX V (5M1270) CPLD configures Cyclone V (5CEBA5) FPGA. We program the CPLD with a PFL_loader.pof. This allows the CPLD to access the flash on the board. We then program the flash with a .pof (I believe this is generated via convert programming files tool). We then program the MAX V with the PFL_configure.pof. We currently use fast passive parallel (FPP) configuration scheme. Page 0 golden copy for final backup Page 1 Old version Page 2 Most recent New requirement: CPLD MAX V will have to choose which one of the above pages to use RSU (Remote System Upgrade) will write RBF file to the flash (RSU just updates the flash memory) Our Configuration part could stay the same (because its already been done). Currently configuring FPGA using Parallel Flush Loader (PFL). Is Remote Update Intel IP compatible with the PFL intel IP ie can it be interfaced? The 'Image update circuitry' block shown in fig17 of the Parallel flash loader intel FPGA IP User Guide could that be used as the Remote Update Intel IP ? Also wrt fig.17 of the same user guide, is there a 'watchdog timer reset circuitry' IP available or is this expected to be coded by the user ? --- I was reading today the PFL IP core User Guide and 1.3.6 Using Remote System Upgrade states when we instantiate the PFL IP core in the Intel CPLD for FPP (Fast Passive Parallel) scheme we can use the features in the PFL IP core to perform remote system upgrade. We can achieve the remote system upgrade capabilities with the PFL IP core by controlling the fpga_pgm[2..0] and the pf1_nreconfigure ports via user defined logic described in 1.3.6.2 of the PFL IP core User Guide. Wrt this statement does this mean that RSU IP is not used? or RSU IP can be connected up (ie interfaced) with the PFL IP core as stated above (ref to fig17 of the Parallel flash loader intel FPGA IP User Guide) ? The User logic block shown within the CPLD (see fig.17) is that vhdl code the user needs to write? If both (RSU IP & PFL IP) require to be connected, is there an example design available with both of these blocks available or a more detailed block diagram that shows their main connectivity ? Your prompt reply to this matter will be appreciated Regards, Kevin

Outstanding important question wrt this ticket : Q/ Is 'Remote Update Intel IP' compatible with the 'PFL intel IP' ie can the 'Remote Update Intel IP' be used to implement the 'Image update circuitry' block (shown in fig17 of the Parallel Flash Loader Intel FPGA IP User Guide) within the Cyclone V (5CEBA5) FPGA and be then interfaced with the CPLD MAX V (5M1270) internal PFL and still able to use Fast Passive Parallel (FPP) x16 (16bits) configuration scheme ?

Will appreciate if someone replies to my ticket. Very urgent please.. My latest review comments follow : Wrt https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf The PFL IP core User Guide: Section 1.3.6 (pg19) wrt .pdf link above, states the following : "When you instantiate the PFL IP core in the Intel CPLD for FPP or PS configuration, youcan use the features in the PFL IP core to perform remote system upgrade" :: "We can achieve the remote system upgrade capabilities with the PFL IP core by controlling the fpga_pgm[2..0] and the pf1_nreconfigure ports via user defined logic" described in 1.3.6.2 (pg21) of the same PFL IP core User Guide. Can I simply implement the state machine shown in fig.16 (pg20) for the 'User logic' block shown in fig17 (pg21) to generate/control the fpga_pgm[2:0] & pfl_nreconfigure signals ? I assume here that the 'User Logic' has to be designed by the user in vhdl and this is the state machine shown in fig16 (pg20). Please confirm. As stated already we have the FPP configuration scheme working with the PFL IP core including programming the MAX5 CPLD with the loader.pof that gives access to the flash (CFI_1Gb) and we will like to keep this functionality. What is the reason for dotted connectivity line --- shown in fig17 from the PFL/flash back to the FPGA ? If the 'User Logic' within the CPLD can achieve the 'remote system upgrade' capabilities with the implemented state machine in fig16 (as stated above), what is the 'Image Update circuitry' block (ref, Fig17) reason within the FPGA? Could that be when using a Serial Configuration scheme and that block could implement the Remote System Upgrade for Serial Configuration devices only (eg instantiating the Remote Update Intel FPGA IP which as I believe from what I seen so far only supports Serial Configuration devices and not FPP or PS) ? Please comment here. I understand that we may require the 'Watchdog timer reset circuitry' functionality within the FPGA and connectivity to the PFL. This can be implemented in VHDL within the Cyclone V FPGA and it's output connected to the pfl_reset_watchdog pin of the PFL. I just opened our Parallel Flash Loader II Intel FPGA IP (parallel_flash_loader_2_0) on the IP catalog and I could not see the pfl_reset_watchdog listed as an input port. Looked at all the options that could be enabled but could still not see that pin being listed. How do I enable the PFL_RSU_WATCHDOG_ENABLED option to see the pfl_reset_watchdog input pin been generated? Please comment here too. The Remote Update Intel FPGA IP includes the watchdog internal circuitry but it will be waste of IP usage if the other functionality related to remote system upgrade for serial configuration devices is not used.

Hi,Please find my response below:[1] Can I simply implement the state machine shown in fig.16 (pg20) for the 'User logic' block shown in fig17 (pg21) to generate/control the fpga_pgm[2:0] & pfl_nreconfigure signals ?I assume here that the 'User Logic' has to be designed by the user in vhdl and this is the state machine shown in fig16 (pg20). Please confirm.Yes, you can.[2] What is the reason for dotted connectivity line --- shown in fig17 from the PFL/flash back to the FPGA ?FPL is actually interacting with flash to get the bitstream stored and program the FPGA.[3] If the 'User Logic' within the CPLD can achieve the 'remote system upgrade' capabilities with the implemented state machine in fig16 (as stated above), what is the 'Image Update circuitry' block (ref, Fig17) reason within the FPGA? Could that be when using a Serial Configuration scheme and that block could implement the Remote System Upgrade for Serial Configuration devices only (eg instantiating the Remote Update Intel FPGA IP which as I believe from what I seen so far only supports Serial Configuration devices and not FPP or PS) ? Please comment here.Fig16 states that we can use PFL IP to write images into flash and also perform reconfiguration to load new images into it. User will need to create their own user logic to remotely send the image to PFL. Whereas Fig17 indicates the component when Intel Remote Update IP is used.[4] I understand that we may require the 'Watchdog timer reset circuitry' functionality within the FPGA and connectivity to the PFL. This can be implemented in VHDL within the Cyclone V FPGA and it's output connected to the pfl_reset_watchdog pin of the PFL. I just opened our Parallel Flash Loader II Intel FPGA IP (parallel_flash_loader_2_0) on the IP catalog and I could not see the pfl_reset_watchdog listed as an input port. Looked at all the options that could be enabled but could still not see that pin being listed. How do I enable the PFL_RSU_WATCHDOG_ENABLED option to see the pfl_reset_watchdog input pin been generated? Please comment here too. You need to turn on the option during IP creation. The option will be available if you change the operating mode to "Flash Programming and FPGA configuration".https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf (Page 40)Thank You.Regards,Bruce

Hi Bruce, Thanks for your reply so far. Wrt your latest comments, will appreciate your latest review comments to the following : >> [2] What is the reason for dotted connectivity line --- shown in fig17 from the PFL/flash back to >> the FPGA ? >> FPL is actually interacting with flash to get the bitstream stored and program the FPGA. FPL? Do you mean PFL (Parallel Flash Loader) ? Page 19 of the Parallel Flash Loader Intel FPGA IP User Guide states : "We can download a new configuration image from a remote location, store it in theflash memory device, and direct the PFL IP core to trigger an FPGA reconfiguration toload the new configuration image" From your next statement ".. User will need to create their own user logic to remotely send the image to PFL" : We will also require the 'Image Update Circuitry' functionality within our Cyclone V FPGA (wrt fig17 of the PFL Intel FPGA IP User Guide) and we will like if possible to use the 'Remote Update Intel FPGA IP' (option 1 - our preferred option BUT see below ..) Otherwise (option 2) will have to implement our own User 'Image Update Circuitry' logic to implement this functionality. You confirmed that we can add other circuitry to implement the 'Image Update Circuitry' logic. Has anyone else implemented a similar design (option2)? Do you have any example design to suggest for the type of devices we are using ? We are using FPP configuration mode 1Gb Flash 16 bits (instantiating an altera_paraller_flash_loader_0 ie not the version II ie altera_paraller_flash_loader_2) and will like to maintain this FPP configuration working. We instantiate the PFL IP core in the MAXV CPLD for Fast Passive Parallel (FPP) configuration and planning to use the features in the PFL IP core to perform Remote System Upgrade. In Option1, can we use a Serial-to-Parallel conversion (S2P) to the serial output data and address of the 'Remote Update Intel FPGA IP' output serial Data/Address to generate parallel Data/Address to our parallel flash ? And to use a S2P could the configuration device be a PS one or AS type from the list below of available configuration devices? I believe here it should be PS so when convert to parallel it will be still passive type. Please clarify here. The 'Remote Update Intel IP Configuration' devices it lists for our Cyclone V FPGA look to be all serial configuration ones & the 1st 4 look to be active serial! Is any type listed Passive Serial ? None of them below look to be parallel types. Please comment here too. EPCS1/4/16/64/128 EPCQ16/32/6/128/256/512 EPCQL256/512/1024 EPCQ4A/16A/32A/64A/128A MX25L128/256/512 MX25U128/256/512 MX66U1G/2G S25FL128/256/512 MT25QL256/512 MT25QU256/512/01G

Hi,Please find my response below:[1] FPL? Do you mean PFL (Parallel Flash Loader) ? Yes, it is Parallel Flash Loader (PFL).[2] We will also require the 'Image Update Circuitry' functionality within our Cyclone V FPGA (wrt fig17 of the PFL Intel FPGA IP User Guide) and we will like if possible to use the 'Remote Update Intel FPGA IP' (option 1 - our preferred option BUT see below ..) Otherwise (option 2) will have to implement our own User 'Image Update Circuitry' logic to implement this functionality. You confirmed that we can add other circuitry to implement the 'Image Update Circuitry' logic. Has anyone else implemented a similar design (option2)? Do you have any example design to suggest for the type of devices we are using ?Yes, as stated above. User can create their own 'Image Update Circuitry' or use Intel Remote Update IP for remote updating functionality. Apologize that do we not have any example design for option 2.[3] We are using FPP configuration mode 1Gb Flash 16 bits (instantiating an altera_paraller_flash_loader_0 ie not the version II ie altera_paraller_flash_loader_2) and will like to maintain this FPP configuration working. We instantiate the PFL IP core in the MAXV CPLD for Fast Passive Parallel (FPP) configuration and planning to use the features in the PFL IP core to perform Remote System Upgrade. In Option1, can we use a Serial-to-Parallel conversion (S2P) to the serial output data and address of the 'Remote Update Intel FPGA IP' output serial Data/Address to generate parallel Data/Address to our parallel flash? And to use a S2P could the configuration device be a PS one or AS type from the list below of available configuration devices? I believe here it should be PS so when convert to parallel it will be still passive type. Please clarify here.To use Remote Update IP, we need to select configuration mode in Quartus as Active Serial mode. So for this scenario, PS for configuration and AS for remote update, I would suggest to use the flash which are supported by both scheme.You can find the list of flash devices supported by PFL IP:https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf (Page 4)Thank You.Regards,Bruce

Implement a Remote System Upgrade in FPGA fabric

23 Replies

Knug
Contributor
5 years ago
Outstanding important question wrt this ticket :

Q/ Is 'Remote Update Intel IP' compatible with the 'PFL intel IP' ie can the 'Remote Update Intel IP' be used to implement the 'Image update circuitry' block (shown in fig17 of the Parallel Flash Loader Intel FPGA IP User Guide) within the Cyclone V (5CEBA5) FPGA and be then interfaced with the CPLD MAX V (5M1270) internal PFL and still able to use Fast Passive Parallel (FPP) x16 (16bits) configuration scheme ?
Knug
Contributor
5 years ago
Will appreciate if someone replies to my ticket. Very urgent please..

My latest review comments follow :

Wrt https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf

The PFL IP core User Guide: Section 1.3.6 (pg19) wrt .pdf link above, states the following :

"When you instantiate the PFL IP core in the Intel CPLD for FPP or PS configuration, you
can use the features in the PFL IP core to perform remote system upgrade"

::

"We can achieve the remote system upgrade capabilities with the PFL IP core by controlling the fpga_pgm[2..0] and the pf1_nreconfigure ports via user defined logic" described in 1.3.6.2 (pg21) of the same PFL IP core User Guide.

Can I simply implement the state machine shown in fig.16 (pg20) for the 'User logic' block shown in fig17 (pg21) to generate/control the fpga_pgm[2:0] & pfl_nreconfigure signals ?

I assume here that the 'User Logic' has to be designed by the user in vhdl and this is the state machine shown in fig16 (pg20). Please confirm.

As stated already we have the FPP configuration scheme working with the PFL IP core including programming the MAX5 CPLD with the loader.pof that gives access to the flash (CFI_1Gb) and we will like to keep this functionality.

What is the reason for dotted connectivity line --- shown in fig17 from the PFL/flash back to the FPGA ?

If the 'User Logic' within the CPLD can achieve the 'remote system upgrade' capabilities with the implemented state machine in fig16 (as stated above), what is the 'Image Update circuitry' block (ref, Fig17) reason within the FPGA? Could that be when using a Serial Configuration scheme and that block could implement the Remote System Upgrade for Serial Configuration devices only (eg instantiating the Remote Update Intel FPGA IP which as I believe from what I seen so far only supports Serial Configuration devices and not FPP or PS) ? Please comment here.

I understand that we may require the 'Watchdog timer reset circuitry' functionality within the FPGA and connectivity to the PFL. This can be implemented in VHDL within the Cyclone V FPGA and it's output connected to the pfl_reset_watchdog pin of the PFL. I just opened our Parallel Flash Loader II Intel FPGA IP (parallel_flash_loader_2_0) on the IP catalog and I could not see the pfl_reset_watchdog listed as an input port. Looked at all the options that could be enabled but could still not see that pin being listed. How do I enable the PFL_RSU_WATCHDOG_ENABLED option to see the pfl_reset_watchdog input pin been generated? Please comment here too.

The Remote Update Intel FPGA IP includes the watchdog internal circuitry but it will be waste of IP usage if the other functionality related to remote system upgrade for serial configuration devices is not used.
YuanLi_S_Intel
Regular Contributor
5 years ago
Hi,

Please find my response below:
[1] Can I simply implement the state machine shown in fig.16 (pg20) for the 'User logic' block shown in fig17 (pg21) to generate/control the fpga_pgm[2:0] & pfl_nreconfigure signals ?
I assume here that the 'User Logic' has to be designed by the user in vhdl and this is the state machine shown in fig16 (pg20). Please confirm.
Yes, you can.

[2] What is the reason for dotted connectivity line --- shown in fig17 from the PFL/flash back to the FPGA ?
FPL is actually interacting with flash to get the bitstream stored and program the FPGA.

[3] If the 'User Logic' within the CPLD can achieve the 'remote system upgrade' capabilities with the implemented state machine in fig16 (as stated above), what is the 'Image Update circuitry' block (ref, Fig17) reason within the FPGA? Could that be when using a Serial Configuration scheme and that block could implement the Remote System Upgrade for Serial Configuration devices only (eg instantiating the Remote Update Intel FPGA IP which as I believe from what I seen so far only supports Serial Configuration devices and not FPP or PS) ? Please comment here.
Fig16 states that we can use PFL IP to write images into flash and also perform reconfiguration to load new images into it. User will need to create their own user logic to remotely send the image to PFL. Whereas Fig17 indicates the component when Intel Remote Update IP is used.

[4] I understand that we may require the 'Watchdog timer reset circuitry' functionality within the FPGA and connectivity to the PFL. This can be implemented in VHDL within the Cyclone V FPGA and it's output connected to the pfl_reset_watchdog pin of the PFL. I just opened our Parallel Flash Loader II Intel FPGA IP (parallel_flash_loader_2_0) on the IP catalog and I could not see the pfl_reset_watchdog listed as an input port. Looked at all the options that could be enabled but could still not see that pin being listed. How do I enable the PFL_RSU_WATCHDOG_ENABLED option to see the pfl_reset_watchdog input pin been generated? Please comment here too.
You need to turn on the option during IP creation. The option will be available if you change the operating mode to "Flash Programming and FPGA configuration".
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf (Page 40)

Thank You.

Regards,
Bruce
- Knug
  Contributor
  5 years ago
  Hi Bruce,
  
  Thanks for your reply so far.
  
  Wrt your latest comments, will appreciate your latest review comments to the following :
  
  >> [2] What is the reason for dotted connectivity line --- shown in fig17 from the PFL/flash back to >> the FPGA ?
  
  >> FPL is actually interacting with flash to get the bitstream stored and program the FPGA.
  
  FPL? Do you mean PFL (Parallel Flash Loader) ?
  
  Page 19 of the Parallel Flash Loader Intel FPGA IP User Guide states :
  
  "We can download a new configuration image from a remote location, store it in the
  flash memory device, and direct the PFL IP core to trigger an FPGA reconfiguration to
  load the new configuration image"
  
  From your next statement ".. User will need to create their own user logic to remotely send the image to PFL" :
  
  We will also require the 'Image Update Circuitry' functionality within our Cyclone V FPGA (wrt fig17 of the PFL Intel FPGA IP User Guide) and we will like if possible to use the 'Remote Update Intel FPGA IP' (option 1 - our preferred option BUT see below ..)
  
  Otherwise (option 2) will have to implement our own User 'Image Update Circuitry' logic to implement this functionality. You confirmed that we can add other circuitry to implement the 'Image Update Circuitry' logic. Has anyone else implemented a similar design (option2)? Do you have any example design to suggest for the type of devices we are using ?
  
  We are using FPP configuration mode 1Gb Flash 16 bits (instantiating an altera_paraller_flash_loader_0 ie not the version II ie altera_paraller_flash_loader_2) and will like to maintain this FPP configuration working. We instantiate the PFL IP core in the MAXV CPLD for Fast Passive Parallel (FPP) configuration and planning to use the features in the PFL IP core to perform Remote System Upgrade.
  
  In Option1, can we use a Serial-to-Parallel conversion (S2P) to the serial output data and address of the 'Remote Update Intel FPGA IP' output serial Data/Address to generate parallel Data/Address to our parallel flash ? And to use a S2P could the configuration device be a PS one or AS type from the list below of available configuration devices? I believe here it should be PS so when convert to parallel it will be still passive type. Please clarify here.
  
  The 'Remote Update Intel IP Configuration' devices it lists for our Cyclone V FPGA look to be all serial configuration ones & the 1st 4 look to be active serial! Is any type listed Passive Serial ? None of them below look to be parallel types. Please comment here too.
  
  EPCS1/4/16/64/128
  
  EPCQ16/32/6/128/256/512
  
  EPCQL256/512/1024
  
  EPCQ4A/16A/32A/64A/128A
  
  MX25L128/256/512
  
  MX25U128/256/512
  
  MX66U1G/2G
  
  S25FL128/256/512
  
  MT25QL256/512
  
  MT25QU256/512/01G
YuanLi_S_Intel
Regular Contributor
5 years ago
Hi,
Please find my response below:
[1] FPL? Do you mean PFL (Parallel Flash Loader) ?
Yes, it is Parallel Flash Loader (PFL).
[2] We will also require the 'Image Update Circuitry' functionality within our Cyclone V FPGA (wrt fig17 of the PFL Intel FPGA IP User Guide) and we will like if possible to use the 'Remote Update Intel FPGA IP' (option 1 - our preferred option BUT see below ..)

Otherwise (option 2) will have to implement our own User 'Image Update Circuitry' logic to implement this functionality. You confirmed that we can add other circuitry to implement the 'Image Update Circuitry' logic. Has anyone else implemented a similar design (option2)? Do you have any example design to suggest for the type of devices we are using ?
Yes, as stated above. User can create their own 'Image Update Circuitry' or use Intel Remote Update IP for remote updating functionality. Apologize that do we not have any example design for option 2.
[3] We are using FPP configuration mode 1Gb Flash 16 bits (instantiating an altera_paraller_flash_loader_0 ie not the version II ie altera_paraller_flash_loader_2) and will like to maintain this FPP configuration working. We instantiate the PFL IP core in the MAXV CPLD for Fast Passive Parallel (FPP) configuration and planning to use the features in the PFL IP core to perform Remote System Upgrade.

In Option1, can we use a Serial-to-Parallel conversion (S2P) to the serial output data and address of the 'Remote Update Intel FPGA IP' output serial Data/Address to generate parallel Data/Address to our parallel flash? And to use a S2P could the configuration device be a PS one or AS type from the list below of available configuration devices? I believe here it should be PS so when convert to parallel it will be still passive type. Please clarify here.
To use Remote Update IP, we need to select configuration mode in Quartus as Active Serial mode. So for this scenario, PS for configuration and AS for remote update, I would suggest to use the flash which are supported by both scheme.
You can find the list of flash devices supported by PFL IP:
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf (Page 4)
Thank You.
Regards,
Bruce
- Knug
  Contributor
  5 years ago
  Wrt your reply statement
  
  "To use Remote Update IP, we need to select configuration mode in Quartus as Active Serial mode. So for this scenario, PS for configuration and AS for remote update, I would suggest to use the flash which are supported by both scheme"
  
  The Remote Update IP just asks which configuration device will be using? It does not ask to select whether is PS or AS scheme.
  
  Our PFL we are using only supports Passive configuration scheme, not Active !
  
  Our choice is to use the Remote Update IP for the remote updating functionality. It was my understanding that there is no idea of the type of configuration PS, FPP or PS in the Remote Update circuitry. It's just pure data & address lines going from RSU to the flash. Isn't this the case?
  
  The issue with the Remote Update IP is that it does not support the flash device we are currently using. We are trying to create other architecture of flash to be compatible.
  
  eg If we select for our Parallel Flash Loader (PFL) the following setup :
  
  Target flash : Quad SPI
  
  How many flash devices? 4
  
  Quad SPI flash density: QSPI 256Mbit
  
  ie (256Mbit * 4 -> 1Gbit)
  
  & FPGA configuration scheme -> FPPx16 (It gives us this option here for this target flash) or PS (prefer to leave it as FPP. This is Passive support and not Active)
  
  & for the Remote Update IP we choose MT25QU01G configuration device from the list of configuration devices, will this setup work with the above PFL setup ?
  
  We don't have much choice wrt our PFL library. Our MAX V CPLD uses PFL configuring using Passive scheme (FPP) to do the configuration. We could change it to PS but it has to be Passive not Active.
  - Knug
    Contributor
    5 years ago
    I created a new project targeting Cyclone V 5CEBA5F23C8 device,
    
    I parameterised the Remote Update IP with the following settings :
    
    Which operation mode will you be using ? REMOTE
    
    Which configuration device you will be using ? MT25QU01G
    
    Enabled all 3 options :
    
    Add support for writing configuration parameters
    
    Add support for Avalon interface
    
    Enable reconfig POF checking
    
    Created the VHDL for this IP.
    
    Added manually the generated .qip under synthesis directory to the Quartus project.
    
    Compile/elaboration was ok BUT got the following Errors during Fitting :
    
    Info (171003): Fitter is performing an Auto Fit compilation, which may decrease Fitter effort to reduce compilation time
    
    Error (169310): Design has remote update block "rsu_remote_update_0_remote_update_0:remote_update_0|altera_remote_update_core:remote_update_core|sd1", but the selected configuration scheme "Passive Serial" does not support remote update
    
    >> The configuration device chosen 'MT25QU01G' from this warning looks to be detected as a PS one >> and this does not support remote update.
    
    >> What configuration schemes does the Remote Update block offer? Only Active Serial (AS) ?
    
    >> Please reconfirm.
    
    --
    
    Info (11798): Fitter preparation operations ending: elapsed time is 00:00:00
    
    Error (11802): Can't fit design in device. Modify your design to reduce resources, or choose a larger device. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
    
    I did not include any pin assignments but left the tool initially do default fitting. Was very surprised from the above 2nd error message (11802).
    
    Looked at the 'Fitter Resource Usage Summary' and seen ALMS <1% usage, LABs 1%, Logic registers < 1%, I/O pins 49%, Remote Update blocks 100% (1/1 used). Cannot see any resources used > 100%. Why I get this error message "Error (11802): Can't fit design in device. Modify your design to reduce resources, or choose a larger device"?
    
    -----
    
    Tried the same flow above but with the following parameter setups :
    
    Which operation mode will you be using ? REMOTE
    
    Which configuration device you will be using ? S25FL512
    
    Unticked all 3 options below :
    
    Add support for writing configuration parameters
    
    Add support for Avalon interface
    
    Enable reconfig POF checking
    
    Still get the following error :
    
    Error (169310): Design has remote update block "rsu_remote_update_0_remote_update_0:remote_update_0|altera_remote_update_core:remote_update_core|sd1", but the selected configuration scheme "Passive Serial" does not support remote update
    
    Tried also : MX25L256, EPCS128, EPCQ128, EPCQ128A , MX66U1G under "Which configuration device you will be using ?" but still get the same error as above.
    
    Noticed in the Fitter / Device options, the Configuration Scheme listed was : Passive Serial (not able to update). Did it detect this scheme from the Configuration device selected ?
    
    How can I resolve this error ?
    
    The quartus tool we are using is 20.1 Lite Edition (not the standard or Pro versions). Any issues with the Lite Edition ?
YuanLi_S_Intel
Regular Contributor
5 years ago
Hi,
Please find my response below:
[1] Please re-confirm that the 'Remote Update IP' can only support AS configuration scheme. If this is the case this 'Remote Update IP' will not be suitable since our parallel flash loader (PFL) only supports just Passive Configuration (PC) scheme (that could be FPP or PS, our choice would be to keep it FPP)

This looks like a stopper for us at the moment trying to use this IP if it only supports AS configuration scheme !
To use remote update IP, the configuration scheme needs to be set as Active Serial x1 / x4.
Yes, for your scenario, since you are using PFL IP already. I would suggest that you send the configuration image remotely via I2C to the CPLD (MAX 10), then store the image into the flash with the use of PFL IP.
[2] What we initially require is once we receive the configuration image from remote location via I2C to then store it in the configuration device. Is this a simple receive serial data and store it in a memory ready to be send to the the flash device?
Yes, it can be done in this way. Then, only trigger reconfiguration with the use of PFL IP by pointing to them start address that the new image is stored in.
[3] Does the remote update IP receive the configuration image internally in a special format (ie Active Serial) before it gets stored in the configuration device that needs (flash) that requires support for AS scheme too?
The IP needs to be working in Active Serial mode.
[4] If we have to end up writing our own 'user logic' vhdl code to do this 'Image Update circuitry' in the Cyclone V FPGA, if special formatting is required before forwarding it to the flash (in our case FPP scheme is used) does it required to be of passive nature so that the flash recognizes it or can it be just bare 16-bit parallel data?
If you are using FPP scheme, the bitstream that you need to write into the flash is POF. The data needs to be send in / out in parallel way.
[5] The Remote Update IP has also a POF checking feature (detecting & verifying the existence of an application configuration image before an image is loaded) to avoid loading an invalid application configuration image that could lead to unexpected behaviour of the FPGA including system failure.

The 'User logic' must take care of this too. Isn't this the case?
Yes. It doesn’t necessary for user logic to implement this checking. It is just a checking. Most importantly is able to update the image remotely to the flash.
Thank You.
- Knug
  Contributor
  5 years ago
  Hi @YuanLi_S_Intel ,
  
  Thanks for your replies so far.
  
  >> Yes, for your scenario, since you are using PFL IP already. I would suggest that you send the configuration image remotely via I2C to the CPLD (MAX 10), then store the image into the flash with the use of PFL IP.
  
  >> Since you are using PFL IP already, there is no point in using Remote Update IP as it requires AS mode
  
  >> So, you can implement you own logic to remotely send the bitstream via JTAG / UART / I2C to the MAX10 and then use the PFL to send to bitstream into the flash.
  
  We are using MAX V CPLD and not MAX10 in our current platform.
  
  >> [2] What we initially require is once we receive the configuration image from remote location via >> I2C to then store it in the configuration device. Is this a simple receive serial data and store it in a memory ready to be send to the the flash device?
  
  >> Yes, it can be done in this way. Then, only trigger reconfiguration with the use of PFL IP by pointing to them start address that the new image is stored in.
  
  1) Can we just implement our own logic circuitry (without the use of the Remote Update IP) to remotely send the new application image data (just chunk bare data) from our external host via I2C serially to the Cyclone V FPGA (convert it from Serial-2-Parallel) and then load/update/store it to the PFL (PFL is within CPLD MAX V) new sector location as parallel data ready to program the flash?
  
  2) The data/address obviously will be converted to parallel data from serial for the PFL to accept but does it need to be recognized also as Fast Passive Parallel (FPP) nature (i.e do we need a similar architecture for updating the data or we don't require any fancy circuit to do this?) before it's been loaded to the PFL so that the Flash then gets programmed ok?
  
  (Note: Our FPGA Cyclone V is only connected to a remote host, not the MAX V CPLD)
  
  If configuration should only happen once ie not planning at this stage (after further review with our team members) to re-configure the device (as the Remote Update IP does). We can always revert to the last workable application image or even the factory image if something wrong happens during the loading/storing process. And if configuration fails, nothing happens at the moment with our current system.
  
  From what I've seen from the flash type S29GL-T we are using, we will like to initially just update with the new application image data 1 & 2 at sector 1 and sector 2 respectively by choosing the correct start addresses as follows :
  
  Address range ( [A15:A4] is the Page address, A16 is the Sector number ) :
  
  000[000]0h -> 000[FFF]Fh (Sector 0) - Factory Image
  
  001[000]0h -> 001[FFF]Fh (Sector 1) - Application Image 1
  
  002[000]0h -> 002[FFF]Fh (Sector 2) - Application Image 2
  
  3) Seen also in one of the documents that "Altera recommends storing only 1 application image at 1 sector boundary" as I try to implement above. Is this the case ?
  
  or is it better to just select 'Auto' when converting from .sof -> .pof and let the Quartus tool automatically set the start address for each Page ?
  
  Regards,
  
  Kevin
  - Knug
    Contributor
    5 years ago
    Any reply to my above message please ? This is very URGENT please ..
    
    Question 3 is partially answered in one other of my tickets wrt using 'auto' feature.
- Knug
  Contributor
  5 years ago
  Hi @YuanLi_S_Intel,
  
  Also, wrt one of your other replies above :
  
  >> Yes, for your scenario, since you are using PFL IP already. I would suggest that you send the configuration image remotely via I2C to the CPLD (MAX 10), then store the image into the flash with the use of PFL IP
  
  We are using MAX V not MAX 10 CPLD (as pointed out already). Can we send the configuration image via I2C to CPLD (MAX V), then store the image into the flash with the use of the PFL IP (and not use at all the Remote Update IP) and maintain our current flow using FFP scheme by converting the data/address to parallel before it goes to the PFL?
  
  In my latest ticket was also asking the question whether during this sending/storing into the flash with the use of the PFL IP needs the configuration image data to be recognised as Passive to be able eventually successfully configure the Cyclone V FPGA with that latest programmed image to the flash. Received no reply to this URGENT question !
YuanLi_S_Intel
Regular Contributor
5 years ago
After several understanding from your scenario, I think this is the best way for you. Since you are using PFL IP already, there is no point in using Remote Update IP as it requires AS mode. We can’t have 2 different configuration mode on our FPGA.
So, you can implement you own logic to remotely send the bitstream via JTAG / UART / I2C to the MAX10 and then use the PFL to send to bitstream into the flash.
- Knug
  Contributor
  5 years ago
  Hi @YuanLi_S_Intel ,
  
  We are using PFL IP (FPP Configuration scheme) but this is within a MAX V and not MAX10 CPLD.
  
  Our current platform supports only MAX V CPLD, as pointed out in one of my previous tickets to you.
  
  MAX10 CPLD on the other hand looks to be having an embedded Flash & a "Nios II Processor / On-chip Memory" RSU Controller but the architecture of MAX V CPLD is different !
  
  Please comment here too.
  
  Regards,
  
  Kevin
YuanLi_S_Intel
Regular Contributor
5 years ago
Hi,

Yes, you may use MAX V for that. I don't see any issue in your use case unless you need to use some IP which the max10 has such as NIOS II.

Meanwhile for this:
3) Seen also in one of the documents that "Altera recommends storing only 1 application image at 1 sector boundary" as I try to implement above. Is this the case ?
or is it better to just select 'Auto' when converting from .sof -> .pof and let the Quartus tool automatically set the start address for each Page ?
I believe i have already answered this in your another thread, which you filed multiple thread every day. Let me explain here again, it would be better if you could select auto for every page. You may also set the start address youself but make sure it wont write on the address of the other SOF file and also on the address where the option bits is located in.
- Knug
  Contributor
  5 years ago
  Hi @YuanLi_S_Intel ,
  
  I have seen that message. Thanks.
  
  But, I was referring to the following question there :
  
  Seen also in one of the documents that "Altera recommends storing only 1 application image at 1 sector boundary" as I try to implement above. Is this the case ?
  
  Page 0 - Sector 0
  
  Page 1 - Sector 1
  
  Page 2 - Sector 2
  
  <auto> mode will sort out the start addresses for each Page BUT is it better to store each Page into a different Sector boundary? Does eg <auto> do this ?
  
  If the answer is <auto> can do anything and it ensures not writing on the address of the other SOF files and also on the address where the option bits is located in, that's fine. We can stick to using <auto> for each page & get the start addresses of each page generated automatically by the Quartus tool.
- Knug
  Contributor
  5 years ago
  Hi @YuanLi_S_Intel ,
  
  Thanks for your following reply & sorry for raising other tickets - reason why I did that is because seen no solid complete answers to the previous ones. Will try to keep my main communication to this ticket from now, onwards unless something else new comes up unrelated to this one.
  
  >> Yes, you may use MAX V for that. I don't see any issue in your use case unless you need to use some IP which the max10 has such as NIOS II.
  
  Please see my latest comments :
  
  1) So the data can be any data (doesn't need to be special passive). Does the PFL when it receives the parallel data/address sort this scheme out before the flash is programmed and can then passive configure successfully the Cyclone V FPGA ?
  
  Sorry, to clarify also one of my previous statements. Wrt my other following ticket query, our remote host I2C has just links to our FPGA Cyclone V (and not direct links to the CPLD (MAX V)) before the new application image data gets forwarded to the CPLD (MAX V) with the use of the PFL IP core to program the flash :
  
  Can we just implement our own logic circuitry within Cyclone V FPGA (without the use of the Remote Update IP) to receive remotely the new application image data (just chunk bare data) from our external host via I2C serially (and also convert it from Serial-2-Parallel within the Cyclone V FPGA) and then be able to load/update/store it to the PFL (PFL is within CPLD MAX V) new sector location as parallel data ready to program the flash?
  
  2) Since we instantiate the PFL IP core within CPLD MAX V for FPP or PS configuration we can use the features in the PFL IP core to perform remote system upgrade. My understanding within the CPLD we will need to enable the extra 'pfl_nreconfigure’ port of the PFL & generate the fpga_pgn[2:0] via user logic to implement the state machine diagram as shown in Fig.16 pg20 of the Parallel Flash Loader Intel FPGA IP User Guide
  
  Isn't this the case?
  
  3) So, are we able to still achieve this data transfer via I2C to Cyclone V FPGA through to MAX V CPLD -> PFL_ip with the above suggested implementation use case ? Please re-confirm
  - Knug
    Contributor
    5 years ago
    Hi @YuanLi_S_Intel ,
    
    Please resend me your answers here because I do not see the reply you already sent me listed now.
    
    Read it this morning and went back to read it again but it is not there!
    
    Regards,
    
    Kevin
YuanLi_S_Intel
Regular Contributor
5 years ago
Hi,
Please find my response below:
[1] Seen also in one of the documents that "Altera recommends storing only 1 application image at 1 sector boundary" as I try to implement above. Is this the case ?

Page 0 - Sector 0
Page 1 - Sector 1
Page 2 - Sector 2

<auto> mode will sort out the start addresses for each Page BUT is it better to store each Page into a different Sector boundary? Does eg <auto> do this ?

If the answer is <auto> can do anything and it ensures not writing on the address of the other SOF files and also on the address where the option bits is located in, that's fine. We can stick to using <auto> for each page & get the start addresses of each page generated automatically by the Quartus tool.xxx
Yes, only 1 design (1 SOF) can be stored in 1 page. If you have multiple FPGA to program in 1 chain, then you can have multiple SOF in 1 page.
For Auto mode, the Quartus II software aligns the pages on a 128-Kbyte boundary; for example, if the first valid start address is 0x000000, the next valid start address is an increment of 0x20000. I think it will not overlap the address.
2) So the data can be any data (doesn't need to be special passive). Does the PFL when it receives the parallel data/address sort this scheme out before the flash is programmed and can then passive configure successfully the Cyclone V FPGA ?
As long as you are programming into flash with POF generated from our Quartus programmer, then it can be configure the Cyclone V successfully.

3) Sorry, to clarify also one of my previous statements. Wrt my other following ticket query, our remote host I2C has just links to our FPGA Cyclone V (and not direct links to the CPLD (MAX V)) before the new application image data gets forwarded to the CPLD (MAX V) with the use of the PFL IP core to program the flash :

Can we just implement our own logic circuitry within Cyclone V FPGA (without the use of the Remote Update IP) to receive remotely the new application image data (just chunk bare data) from our external host via I2C serially (and also convert it from Serial-2-Parallel within the Cyclone V FPGA) and then be able to load/update/store it to the PFL (PFL is within CPLD MAX V) new sector location as parallel data ready to program the flash?
Yes, you can do that.
4) Since we instantiate the PFL IP core within CPLD MAX V for FPP or PS configuration we can use the features in the PFL IP core to perform remote system upgrade. My understanding within the CPLD we will need to enable the extra 'pfl_nreconfigure’ port of the PFL & generate the fpga_pgn[2:0] via user logic to implement the state machine diagram as shown in Fig.16 pg20 of the Parallel Flash Loader Intel FPGA IP User Guide

Isn't this the case?
Yes you are right.
4) So, are we able to still achieve this data transfer via I2C to Cyclone V FPGA through to MAX V CPLD -> PFL_ip with the above suggested implementation use case ? Please re-confirm
Yes you can.
Thank You.
Regards,
Bruce
YuanLi_S_Intel
Regular Contributor
5 years ago
We realised that this is thread is a duplicated thread of 04988636. I am now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Forum Discussion

Implement a Remote System Upgrade in FPGA fabric

23 Replies

Recent Discussions

Agilex 5 GTS Supported Protocols

GTS System with NIOS & MSGDMA

Reconfigure Agilex-7 with PCI IP causes system reboot

Stratix-10G FPGA Transceiver Configuration for Ethernet MAC 100G Controller

What Bank Mode of LPDDR5 does Agilex 5 support?