Occasional Contributor
Super Contributor
@tedh4ddv wrote:Currently the design provides the processor access to the serial configuration flash device via a SPI Flash Loader Platform (SPISlaveToAvalonMasterBridge and SPI_flash_platform_sfl_av_bridge). To utilize the Remote Update IP Core, I think the SPI_flash_platform_sfl_av_bridge should be removed, and the Remote Update IP Core would connect to the SPISlaveToAvalonMasterBridge via an Avalon MM interconnect. Does this sound reasonable?
There are basically two tasks that have to be performed in an RSU aware design:- switching between different images during FPGA configuration load. That's the Remote Update IP task
- updating and verifying application image(s) in flash in FPGA user mode. This is achieved by a suitable flash loader IP, either using low level register or e.g. MM interface
Both components are usually separated in your design, in some cases remote update IP has an interface to flash to check image crc before loading it
Occasional ContributorAs I mentioned, we currently have a SPI_to_SerialFlashLoader platform in the design. We want to keep that function in place for loading new Flash images. When adding the SPI_to_RSU platform, which will be comprised of a SPI_To_AvalonMaster plus the RU Core, how is access to the Serial Flash interface handled? Do I require external multiplexing for the DCLK, DOUT, DIN and nCE pins? Or can the new SPI_to_RSU Platform handle both functions?
Occasional ContributorAsking more simply, does the RSU Core handle the loading of a new .jic file into serial flash along with handling the switching between configurations?
Occasional Contributor...or would I need to connect the Avalon output from the SPI_to_AvalonMaster core to both the Remote_Update core AND the AvalonSlave_to_SFL cores?
