FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

Implement a Remote System Upgrade in FPGA fabric

Knug
Beginner
1,438 Views

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

0 Kudos
23 Replies
Knug
Beginner
1,283 Views

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 

 

0 Kudos
Knug
Beginner
1,264 Views

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.

0 Kudos
YuanLi_S_Intel
Employee
1,252 Views

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


0 Kudos
Knug
Beginner
1,249 Views

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

 

0 Kudos
YuanLi_S_Intel
Employee
1,222 Views

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


0 Kudos
Knug
Beginner
1,217 Views

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.

 

 

 

0 Kudos
Knug
Beginner
1,214 Views

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 ?

 

0 Kudos
Knug
Beginner
1,211 Views
I managed to get the Remote Update IP to resolve both errors with eg MT25QU01G selected (the other S25FL512 went through quartus flow too without any error) and carry on complete fitter stage (seen initially timing violations + unconstrained ports, this was not a concern yet). The configuration scheme by the quartus tool was always defaulting to PS mode. I had to go to 'Assignments' / 'Device' / 'Device and pin options' and change the configuration scheme to Active Serial x1 (can use configuration device). Can select which configuration device to use from the drop box (set to 'auto' by default). All the devices listed there are EPCS / EPCQ types only for AS configuration mode. Can also change configuration mode there to : 'Remote' from 'Standard'. The other Parallel Configuration schemes PPx16 & PS do not allow me to choose a configuration device. That option is greyed out and it looks like the Remote Update IP can only support AS configuration scheme !
 
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)
 
Finally, resolved the timing violations because the tool used default clk constraint of 1000MHz for the clock. Added a constraint file to constrain it to 20MHz ('Remote Update Intel FPGA IP User Guide' core input clock (fMAX) value for Cyclone V -> 20MHz). Left with unconstrained input/output paths (expected to see this at this stage)
0 Kudos
Knug
Beginner
1,190 Views

Hi @YuanLi_S_Intel ,

URGENT - Will appreciate a reply please here too. Monday 1st March in the morning I have to present my findings to the company..

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 ! 

 

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?  

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 ? 

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?

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?

The 'watchdog timer reset circuitry' will be another feature that the 'User_logic' should do but this feature is not as important yet compared to the 'remote update circuitry' stated above

0 Kudos
Knug
Beginner
1,153 Views

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"

OK. Selected the configuration mode in Quartus 20.1 Lite Edition as 'Active mode' and set the Remote Update IP parameter configuration device as 'MT25QU01G'. Managed to compile/elaborate/synthesize & go through fitter stage the Remote Update IP in a standalone project.

What do I do next?

I think the issue is that the Remote Update IP does not support any Passive Configuration scheme ! Is this the case ?

Our normal flow to configure the Cyclone V FPGA without RSU is FFPx16 configuration ie set the PFL (PFL is instantiated within our MAX V CPLD) parameters as follows :

  • Which FPGA Config scheme used ?  FPPx16 (other available options PS, FPP or FPPx32) BUT no AS listed !!
  • Targeted Flash : CFI Parallel Flash

Our on board Flash we are currently using and cannot change is: S29GL01GT, 1Gbit 128Mx8. Our PFL (altera_parallel_flash_loader) only supports PS or FPPx16 configuration scheme!

You suggested using a flash that supports both Active and Passive configuration schemes. Please elaborate further your statement here. Are there such flashes available?

We need to be able to store 2 more application images (image1 & image2) in the Configuration flash memory. Image0 is the golden or fallback image (factory image). Program the new image to the flash on-the-fly during normal system operation and able to re-configure the FPGA with either image, switch between images automatically in case of system error. and at the same time we will like to keep our configuration scheme FPPx16 that works. 

If the RSU can support Passive Serial (PS) configuration scheme we can use a Serial-to-Parallel (16-bits) converter converting the serial data/addr into parallel (16bits) out for out Parallel flash loader. 

Can someone please reply here ?

 

 

0 Kudos
YuanLi_S_Intel
Employee
1,140 Views

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.


0 Kudos
Knug
Beginner
1,126 Views

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

0 Kudos
Knug
Beginner
1,107 Views

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. 

0 Kudos
Knug
Beginner
1,102 Views

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 !

 

0 Kudos
YuanLi_S_Intel
Employee
1,140 Views

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.


0 Kudos
Knug
Beginner
1,136 Views

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

0 Kudos
YuanLi_S_Intel
Employee
1,098 Views

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.


0 Kudos
Knug
Beginner
1,096 Views

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.

0 Kudos
Knug
Beginner
1,092 Views

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

0 Kudos
Knug
Beginner
1,004 Views

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

0 Kudos
Reply