Contributor
Regular ContributorHi,
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.
ContributorHi @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 !
