Contributor
ContributorWrt 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.
ContributorI 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 ?
ContributorContributorHi @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
