Agilex 7 DDR4 Reset and ADDR/CMD Clock PCB Implementation Documentation Discrepancy
Hi, 1. The Agliex 7 F Series EMIF User Guide page 191 Figure 145 of section 6.5.6.3 shows RESET line to DRAM pulled up to VDD with 4.7k ohm resistor and this was implemented on Agilex 7 F series evaluation board DDR4 memory vendor datasheet (thisis publicly available one for the MT40A2G8VA used on above linked eval board) states RESET must be low while power rails ramp up as pictured below which implies it should be instead pulled down to ground. Can Altera explain why they recommend pullup which seems to be opposite of what memory vendor specifies? From above public Micron datasheet 2. Figure 143 in section 6.5.6.1 of Agilex 7 EMIF User Guide shows ADDR/CMD clock terminated to VDD through R and C network. Altera F Tile eval board has ADDR/CMD clock terminated to GND through R and C network. Can Altera explain why the eval board implementation for this signal termination does not match the EMIF user guide figure 143 recommendation? From Eval board Thanks!
Arria 10: Remote Update Factory Fallback won't work & Watchdog does not trigger
Hello, I have to reopen another topic from last year: Arria 10: Remote Update may brick FPGA and Factory Fallback won't work | Altera Community - 315011 Opposed to my comments in the original thread, enabling the watchdog does not trigger a factory fallback if the application Image is wrongly aligned. This brings me back to this scenario of the original post: 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 this scenario might be an 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! We have this boot procedure: Boot into factory image (0x20 as boot address in flash boot sector 0x00 to 0x1F). We have certain HW which is sensible to boot up timing so we need this to guarantee an identical and reliable boot up procedure. Boot from factory load into application image Check for power up boot: Read RU_RECONFIG_TRIGGER_CONDITIONS register for power up state (0) do not reconfigure if Bit 4,2,1,0 is set Set AnF bit: write "1" to RU_CONFIGURATION_MODE Set application image address RU_PAGE_SELECT Enable Watchdog Set RU_WATCHDOG_TIMEOUT & RU_WATCHDOG_ENABLE Reconfigure: write "1" to RU_RECONFIG In Application mode we only read the RU_RECONFIG_TRIGGER_CONDITIONS as status info We do not write the RU_WATCHDOG_ENABLE nor RU_RESET_TIMER registers I have run tests, with a Application Image being stored with an offset of -2 Bytes, i.e. the first 2 Bytes of the Application image are not stored in Flash Memory and the full image is shifted in its Flash storage. In this case, the FPGA gets stuck in an unresponsive state, when trying to load the application image. There is no fallback to the factory load happening, no CRC error, no watchdog triggering. 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! How can I examine/validate a FPGA bitstream in flash memory before executing it? best regards FabianMax10 FPGA Programming with .pof file
Hello All, we are using 10M16 FPGA in our design. Observation is that we are able to program the FPGA using .sof every time but .pof gets installed on most boards 8/10 times and on few boards fails every time. Could you recommend the Hardware requirement for .pof flashing? (We are using USB Blaster II). With .pof, erase happens 100%. Blank check/ Program fails. Thanks and RegardsAgilex 5 RSU, application image addition fails
Dear all, We are trying, unsuccessfully, to add new application images in a Agilex5 based project . We re using am AXE5000 board with an Agilex5 A5EC008BM16AE6S (M16A) model and a 256 Mbit QSPI config Flash memory. We are working with Quartus Prime Pro 25.1.0 version. Following the example here our programming file generator looks like this Below is shown the content of our .map file: BLOCK START ADDRESS END ADDRESS BOOT_INFO 0x00000000 0x0020FFFF FACTORY_IMAGE 0x00210000 0x00357FFF (0x00316FFF) SPT0 0x00358000 0x0035FFFF SPT1 0x00360000 0x00367FFF CPB0 0x00368000 0x0036FFFF CPB1 0x00370000 0x00377FFF P1 0x00378000 0x0048BFFF Configuration device: A5EC008BM16A Configuration mode: Active Serial x4 Notes: - Data checksum for this conversion is 0xE6BCBC7E - All the addresses in this file are byte addresses In this scenario, using system console and the script rsu1.tcl provided , we have been able to switch between Aplication and Factory images flawlessly using "rsu_image_update" function. Then following the mentioned excample, we tryied to add a new application image qspi_open qspi_set_cs program_flash ./output_files/RemoteImage_jic.rpd 0x0048C000 1024 Once finished, we can check how the memory possitions have been written changing from all 0xFFFFFFFF to different values, using : qspi_read 0x0048C000 512 Then, we check the configuration pointer blocks: qspi_read [expr { 0x00368000 + 0x20}] 1 qspi_read [expr { 0x00368000 + 0x28 }] 1 qspi_read [expr { 0x00370000 + 0x20}] 1 qspi_read [expr { 0x00370000 + 0x28}] 1 Here we can see in both pointers how the current application image pointer entry has the value 0x00378000, while the next image pointer entry has all ones 0xFFFFFFFF. Then we update the aplication pointers with: qspi_write_one_word [expr { 0x00368000 + 0x28}] 0x0048C000 qspi_write_one_word [expr { 0x00370000 + 0x28}] 0x0048C000 Using "qspi_read" again we see how the pointer entries which before were all ones 0xFFFFFFFF, now contains the new address 0x0048C000. Then we close the qspi access with "qspi_close". Now, if we restart the system we see how the application image loaded is the one which was originally set on address 0x00378000. Running "rsu_status", we see how the added image failed The failing code returned is not listed in Error Code Responses Could you please help us with this topic? Thanks in advance
MAX10 RSU upgrade succeeds, but device boots Factory image instead of Application
Hello, I’m using Intel MAX10 Remote System Upgrade (RSU) with: CFM0 = Factory CFM1 = Application The firmware‑triggered RSU upgrade completes successfully, but after reconfiguration the device boots back into the Factory image instead of the Application image. Below is the design setup: RSU IP instantiated and connected over SPI Avalon‑MM master interface of RSU IP is exported to user logic onchip_flash data interface is also exported and visible in the top level Firmware performs erase/write/verify through the exported Avalon‑MM interface Autoboot decision is based on a bit stored in UFM, read at startup No external power cycle occurs during RSU (warm reconfiguration). Below are the observations: RSU programming via firmware completes without errors MAX10 reconfigures after RSU Cold boot works correctly Programming the App image via JTAG works Issue occurs only after warm RSU (no power cycle) Autoboot selection is controlled via a bit stored in UFM. For this I have exported the AV-MM I have the below questions: Is it expected that RSU does not automatically re‑enter autoboot logic? After warm RSU, must user RTL explicitly regenerate a boot / autoboot event? Are there recommended MAX10 reference patterns for autoboot handling after RSU? Thanks for any guidance or references.
Cyclone 5 SoC FPGA Bank Supply Prerequisite
Dear Altera Support Team, I am not sure this is correct and did not found much info on Handbook. Device 5CSXF6C6U23 CASE 1: BANK 5A 5B only supplied VCCPD to 2.5V and VCCIO is floated. JTAG scan chain shows both HPS and FPGA devices. JTAG program shows failed with wrong device address. CASE 2: BANK 5A 5B supplied 2.5V or 1.8V VCCIO. JTAG scan chain shows both HPS and FPGA devices. JTAG program shows successful result. Based on the above situation: do BANK 5 must supplied VCCIO in order FPGA to work? I don't understand, other brand FPGA do not have such requirement while VCCPD must be powered which is understandable. Please confirm this for best and safe device HW configuration. Thanks, Brian
MAX10 ADC Problem BANK 1A 1B 8
I have used a max10 chip and quartus 18 for the project. I have encourtered with ADC critical warning (16248). How can I solve this problem. For Bank 1B I can move the pins to other locations but the BANK 8 is vague because it lets some of the pins can be used. However it does not say which pins to be used properly. I have researched about this topic and I have found this source. https://docs.altera.com/r/docs/683751/25.1/max-10-general-purpose-i/o-user-guide/guidelines-analog-to-digital-converter-i/o-restriction Is there other resources that could explain this problem and the solution? what should I do?
