Timing Behavior of Remote Update IP After Reset on Cyclone 10 GX (10CX150YF672E5G)
I am using the Remote Update IP with the Cyclone 10 GX FPGA, part number 10CX150YF672E5G. I observed that the Remote Update IP does not respond properly after reset until approximately 300 µs. I experimented with delays of 1 µs and 2 µs after reset, but did not observe the expected behavior. However, after waiting for 300 µs, the IP responded as expected. Previously, I used the same Remote Update IP with a different part number, 10CX150YF672I5G, and in that case, it worked as expected with just a 10 clock cycle delay after reset. Could you please confirm if there is a specific timing requirement after reset for initializing the Remote Update IP with the 10CX150YF672E5G device? I am using Quartus Prime Pro 24.2 tool for Both version of Cyclone 10GX FPGA(10CX150YF672E5G & 10CX105YF672I5G) Thank you.156Views0likes15CommentsnSTATUS is sometimes asserted low during Agilex-F configuration when operating in PMBus slave mode
I am using Passive Avalon-ST 16 mode to configure the Agilex-F device. There is external PMBus master to run the ARA process of the SmartVID protocol immediately after sensing ALERT low signal. Sometimes when trying configuration after power up (starting the process by asserting nConfig low), nStatus goes low before reaching the point of ALERT signal going low. Retry of the configuration after such failure always succeeds. Any idea? Thanks, Itzik39Views0likes3CommentsLTC Connector DE10-Standard FPGA
I am trying to access the I2C bus on the LTC connector on the DE10 Standard FPGA board. I have enabled the i2c controllers on the HPS. How do I now gain access to the i2c2 pins that are connected to the ltc connector from the HPS? I was able to communicate to the g-sensor that shares the same bus with the ltc connector, but I need to access the LTC connector to communicate with a separate board. I see that there is a TS3A5018 switch. Am I required to set the HPS_LTC_GPIO to low to switch communication from spi to i2c? Kindly help.90Views0likes6CommentsArria 10: Remote Update Watchdog unpredicted behavior
Hello, I start a new thread here, since the previous thread is not answered anymore after the transformation from Intel to Altera Forum. All details and data is still valid from the original thread: Arria 10: Remote Update may brick FPGA and Factory Fallback won't work | Altera Community Main problem is: We have to scenarios (see also here) Misaligned Image: Enable Watchdog in Factory Image trigger reconfiguration (write 1 to RU_RECONFIGURATION_MODE & RU_RECONFIG) Reconfiguration fails due to misaligned image --> Watchdog triggers Fallback to factory mode ==> This case is working as expected. Good Case! Aligned valid Image Enable Watchdog in Factory Image trigger reconfiguration (write 1 to RU_RECONFIGURATION_MODE & RU_RECONFIG) Application Image starts. Application Image does not serve or actively disable the watchdog! Since the application image does not serve the watchdog, I would expect a factory fallback due to watchdog triggering. NOTE: We do not talk about further reconfiguration triggered from within application image. We only do reconfiguration from within the factory load. ==> This is not happening. And I don't understand why. Or is the watchdog automatically disabled once a valid application image is loaded? Critical Questions about the Watchdog timeout register: What is the unit of the watchdog timeout register? This is not specified in its datasheet/documentation. Farabi stated "Please make sure the watchdog timeout not too. eg. Dont set RU_WATCHDOG_TIMEOUT = 0xFFF (this is too long)". Why is this too long? I am missing any restrictions in the respective datasheet. Please advice. Thanks for any help best regards Fabian50Views0likes5CommentsArria 10: Remote Update may brick FPGA and Factory Fallback won't work
Hello, we have observed some critical failures when doing tests with various potential error scenarios concerning a remote Update of the FPGA bitstream in the attached SPI Flash device. We could repeatedly trigger cases, when the FPGA internal fallbeck mechanism to the factory load does not work. We do not use any bitstream encryption. Test scenarios: Erased flash & partially programmed application load image --> Fallback mechanism works as expected Invalid application load image location, i.e. start of application load is shifted by1-10 Byte (Manually induced error scenario) --> The reprogramming sequence starts but never completes and no fallback to the factory load is performed. => The FPGA is completely unresponsive unless programmed via JTAG It is obvious, that the 2nd scenario might be a more exotic error scenario, however we require a robust setup and have to make sure, that the FPGA remains accessible under any circumstances, so we need the Factory Fallback mechanism to work reliable! As a best guess I could assume it might be related to this Note in 1.3.1. Remote System Configuration Mode that the factory fallback mechanism won't work for Arria 10 FPGAs if the last 576 Bytes of the bitstream are corrupted. Note: The fallback to the factory image does not work under the following conditions: If the last 576 bytes of an unencrypted application image bitstream are corrupted. Intel recommends that you examine the last 576 bytes of the unencrypted application image before triggering the application image configuration. But I have noticed that the binary images of the FPGA bitstream vary in size. So there is no way to check explicit memory locations for these 576 Bytes. Is there any way to identify this section? My Questions: Why is the factory configuration fallback mechanism not working in the above described scenario? The Factory load image is valid! What method does intel recommend to reliable make the factory fallback mechanism work? How can I examine/validate a FPGA bitstream in flash memory before executing it? Thanks a lot for any help Best regards Fabian3KViews0likes26CommentsAgilex7 configuration issue
Hi, Some designs are experiencing configuration failures when programming the .sof file into the device via JTAG. I have tested across multiple Quartus versions, including the latest (v25.3), and the affected designs consistently encounter this issue regardless of the version. Further debugging using the Configuration Debugger shows the following: Major Error: 0xF004 – ERR_Internal_error Device Part Number: AGID023R31B2E2V Hardware: Custom board Do you know how to resolve this issue?19Views0likes0CommentsDoes direct connection of two AXI4 Masters to DDR Slave support auto-arbitration on Agilex 5?
Hi all, I'm developing on the Agilex 5 platform and need two AXI4 masters to access the DDR. I noticed there isn't a standalone IP similar to Xilinx's axi_interconnect. Is it correct to simply connect two AXI masters directly to the single DDR AXI slave port (as shown below)? Will the interconnect fabric generate the necessary arbitration and routing logic in this case?Solved113Views0likes10CommentsAgilex Reset_Release no associated clock
Hi, I wonder if anyone can help me with a Platform designer error while using the Agilex Reset release IP. I wanted to combine the nInit_done signal with a couple of external resets to make a global reset. I added the Agilex Reset release IP and I combined it with my external resets in a separate HDL module that I wrote (see attached). I now have a system_platform error telling me that the reset_release IP and my HDL module have to be on the same clock domain (see attached) and that the reset_release IP has no associated clock. Does anyone know how to associate a clock with the reset release IP? I have tried everything I can think of but no luck Thanks40Views0likes2Comments