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 ,
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 ) :
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
ContributorAny 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.
