tedh4ddv
Occasional ContributorJoined 5 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: Remote Update for Cyclone 10 LP - CSR
This design is not based on any GHRD. It is a custom platform built using Quartus Prime Standard version 20.1. With help from an FAE at Arrow Electronics, we've got the CSR addressing straightened out. I can now read back what is written to the base address register... mostly. I do lose the bottom two bits of the data. Now, when I set the RU_RECONFIG bit, the FPGA seems to attempt a reconfiguration, but it fails to complete. There is a Watchdog Timeout indication in the status register.1.7KViews0likes0CommentsSignal Probe - Source node does not exist
I've compiled my project. I've reserved an available pin for Signal Probe output. When I try to Add Signal Probe Pin, the selected node is not found. I see an error: Source node does not exist. Please specify a valid nod. I know the node exists since I can analyze it's behavior in Signal Tap. The node is inside the Remote Update IP Core.Solved1.8KViews0likes3CommentsRemote Update for Cyclone 10 LP - CSR
Using Platform Designer, we've combined three IP Cores in a Cyclone 10 LP project to accomplish three functions: 1) allow an external processor access to the FPGA via a SPI bus 2) write a .jic file to the serial flash configuration device (file is comprised of 2 .sof images) 3) initiate a reconfiguration of the FPGA to the alternate .sof image stored in the flash device. The three IP Cores are: 1) Generic Serial Flash Interface 2) Remote Update 3) SPI Slave to Avalon Master Bridge The project compiles successfully, and the FPGA boots to the .sof image located at flash address 0x0. For test purposes, the platform also contains a scratch register implemented with the PIO (Parallel I/O) IP Core. The scratch registers are read/write accessible which indicates that the SPI Slave to Avalon Master Bridge is operational. We are having an issue with the Remote Update function. It appears we can write to the RU_BOOT_ADDRESS (offset 0x10) in the CSR space, but a read of this address consistently returns 0x0000_0000. Additionally, when we attempt to initiate a reconfiguration, it does not occur. The procedure we are using is: 1) Write the value (0x0040_0000, in this case) to the RU_BOOT_ADDRESS register (offset 0x10). 2) Write the value 0x1 to the RU_RECONFIG register (offset 0x1D). Is this the correct procedure to initiate a reconfiguration or are there additional steps we've overlooked?1.9KViews0likes5CommentsRe: multiple sof fpga configuration files stored in single flash
As 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?2.5KViews0likes2CommentsRe: multiple sof fpga configuration files stored in single flash
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?2.6KViews0likes0Commentsmultiple sof fpga configuration files stored in single flash
I gather that two or more .sof files may be combined to a single .jic file and written to an active serial flash device using the Serial Flash Loader IP core. I am not clear on how the fpga can be triggered to re-configure itself from flash using one of the alternate images not located at address zero.2.7KViews0likes11Comments