Forum Widgets
Recent Discussions
intel_onchip_Memory II RAM: r/w doesn t work from FPGA but from HPS
Hi guys, I try to write and read to/from a intel_onChip Memory 2 RAM. But it only sets the first or the last byte in the RAM to 0x00 depending on how high I set the ram_addr_reg. I am using a Arria10 SOC Development Kit. The initial file is transferred well with all data on the right spot. And I can read and write the RAM from the C-Program on the Linux HPS. But i then try to write something from the FPGA only the first Byte changes to 0x00. This I can overwrite by the C-Programm again. I can do this procedure as often as I want. Do you see any mistake I've made in my code or the setup? Please see code and pic attached. Thanx, LinusSolved66Views0likes5CommentsPower Rating Required for RZQ Resistor on Cyclone V SE
Hi, I need to include the 100R resistor we are using connected to RZQ pin D21 on the 484 ball package. Can anyone tell me what the maximum current I would realistically experience. If I just assumed that the resistor connected directly from a voltage rail through the resistor to ground it would make my resistor too large, physically, thus the need for realistic figures please. Thanks.24Views0likes4CommentsMAX 10. No 3.0 V Schmitt Trigger I/O standard
For some reason Max 10 doesn't support 3.0 V Schmitt Trigger I/O standard. Of course, using 3.3V I/O standard would work as well. But then Quartus would complain and would issue a fatal error if there other pins in the same bank are configured as 3.0 V LVTTL or 3.0 V LVCMOS. I guess I could change all the pins in the same bank to 3.3V, instead of 3.0V. But I don't want to do that because some features are supported on 3.0V but not on 3.3V I/O standard. E.g., configurable slew rate is not available for 3.3V I/O standard. It would seems that something doesn't make much sense. Not sure if it's a real hardware issue or just a Quartus limitation. So the question is how I can enable both the Schmitt Trigger and features such as slew rate control in the same I/O bank. I don't need this in the same pin, at least not in this case,. Or the only workaround is to use something like 2.5V I/O standard? Didn't try, but according to the datasheet 2.5V I/O standard does support both features. Thanks,37Views0likes3CommentsArria 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 Fabian3KViews0likes25CommentsUnable to program EPCQ16A on custom cyclone IV board - error during jic flashing.
Hello, I have created a custom FPGA PCB board with cyclone IV EP4CE6E22C8N FPGA. For flash I have a EPCQ16A. When I try to configure my FPGA in jtag mode MSEL (2:0) = "011", and use the .sof file. - everything is working properly. But when I try to flash using .jic - it fails to program and shows an error. While generating the jic file I did select the correct flash device - EPCQ16A. And I changed my MSEL(2:0) to "010" (AS mode). When I give autodetect before adding the .jic file, it does recognise my FPGA device and after I have added the .jic file I can see the EPCQ16A in the JTAG chain. However, when I program it fails. I have attached the programmer window screenshot and the error message: Info (209060): Started Programmer operation at Thu Nov 27 12:04:37 2025 Info (209016): Configuring device index 1 Info (209017): Device 1 contains JTAG ID code 0x020F10DD Info (209007): Configuration succeeded -- 1 device(s) configured Error (209025): Can't recognize silicon ID for device 1. A device's silicon ID is different from its JTAG ID. Verify that all cables are securely connected, select a different device, or check the power on the target system. Make sure the device pins are connected and configured correctly. Error (209012): Operation failed Info (209061): Ended Programmer operation at Thu Nov 27 12:04:39 2025 Please can anyone tell me where I am going wrong and how to fix it?16Views0likes0CommentsAgilex 5 A5EC065BB32AE5SR0 issue
Hello I built a new board with A5EC065BB32AE5SR0 , I got a issue with the fabric. the FPGA is configurable, and Init done goes to high after configuration . I have a very simple verilog code with PLL output to the pin. But there is no output. could you identify what is the problem here? Atex56Views0likes6CommentsLTC 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.21Views0likes1CommentShift Register triggers occassionally on both clock edges
Good morning community, in my project a MAX10 M08 FPGA serves as an interface between a microcontroller and an ADC board with 32 channels. In order to parallelize the serial data from the board I developed a shift register. This register shall only read the first 512 bits of a data stream. Therefore a counter is included. -- serial-parallel converter synchronous to falling edge of DCLK p_ser_par_dclk : process (DCLK,nRES) is begin if (nRES = '0') then dout0_shr_dclk <= (others => '0'); dout1_shr_dclk <= (others => '0'); mod1023_count_i <= 0; elsif (falling_edge(DCLK)) then -- resets counter when nDRDY active if (nDRDY = '1') then mod1023_count_i <= 0; elsif (mod1023_count_i < 512) then mod1023_count_i <= mod1023_count_i + 1; end if; -- counter masks the 512 DCLK clock edges without data if (mod1023_count_i < 512) then -- shift-registers, alert bit, address bits, CRC bits shifted, maybe later omitted dout0_shr_dclk(0) <= DOUT0; dout1_shr_dclk(0) <= DOUT1; dout0_shr_dclk((snr_length - 1) downto 1) <= dout0_shr_dclk((snr_length - 2) downto 0); dout1_shr_dclk((snr_length - 1) downto 1) <= dout1_shr_dclk((snr_length - 2) downto 0); -- no shifting else dout1_shr_dclk <= dout1_shr_dclk; dout0_shr_dclk <= dout0_shr_dclk; end if; end if; end process p_ser_par_dclk; The data from the AD converters contains the channel number. Therefore there must be regular data patterns in the 512 bit wide vector when a complete set of 16*32bit have been written into the FIFO. I could never see this pattern when I visualized the internal data with the signal tap analyzer. What I can occassionally see is that the shift registers and the counter triggers at the wrong edge. This is a severe error. What could be the reason? Best regards Christof Abt53Views0likes6Comments10AX115H3F34E2SG, Laser marking
Dear INTEL/ALTERA Support Team, Good day. We previously purchased a batch of INTEL/ALTERA components from the authorized distributor ARROW and sold them to my client. Our client has raised concerns about the components having been re-marked. Model: 10AX115H3F34E2SG D/C: 2113, Lot Number: S848AK02TW, COO: Taiwan, Arrow Delivery ID: 011717919 We have received a statement regarding the product markings, which says: "De-mark/Re-mark is a qualified and controlled process within the manufacturing site. There is no impact on quality, reliability, and compliance with specifications on a de-marked/re-marked product." Attached please check our document. Could you please help verify the authenticity of this statement? Is it from Altera? We would greatly appreciate it if you could provide clarification to help address our client’s concerns. Hope to receive your feedback soon. Best regards, Carol Choi23Views0likes0CommentsAgilex 5 Premium Dev Kit SFP Implementation
Hi everyone, I’m working on a design that interfaces with the SFP+ cage on the Agilex 5 Premium Dev Kit. My reference point is the Agilex™ 5E HPS Enhanced System Example Design (from the documentation here: https://altera-fpga.github.io/rel-25.1/embedded-designs/agilex-5/e-series/premium/egsrd/ug-ehps-agx5e-premium/), which targets the QSFP cage using the GTS hard EMAC/PHY. My goal is to take this same framework and retarget it to the SFP+ cage instead. Initially I moved the relevant pins and refclock to the SFP+ bank, but I realized that when using transceiver banks on opposite sides of the device, the design requires two GTS Reset Sequencer IPs, as mentioned in the GTS User Guide: “Two GTS Reset Sequencer IP instances if your design uses transceivers on both sides of the device.” (For now I’m ignoring the SFP+ I2C/I3C management interface — I plan to either route I3C from the HPS to the FPGA or instantiate a soft I2C and add it to the device tree, but first I need to get a clean FPGA build.) Because the example design uses the HPS USB interface, which resides on the opposite side of the SFP+ bank (4A), I suspected this was part of the issue. However, after attempting a full build, I encounter the following error: Error(175006): There is no routing connectivity between source IPFLUXTOP_UXTOP_WRAP and the pin Info(175026): Source: IPFLUXTOP_UXTOP_WRAP soc_inst|cpl_eth_tg_ss_0|intel_eth_gts_0|intel_eth_gts_0|hip_inst|n_channel_superset_wrapper_inst|n_channel_superset|hal_top_wrapper_inst|hal_top_ip|one_lane_inst_0|one_lane_hal_top_p0|gen_non_usb_mode.phy_hal_top_inst|phy_hal_top|phy_hal_coreip_inst|ch4_phy_inst|x_std_ipfluxtop_uxtop_wrap_0 Info(175013): The IPFLUXTOP_UXTOP_WRAP is constrained to the region (185, 7) to (185, 7) due to related logic Info(175015): The I/O pad i_rx_serial_data_n is constrained to the location PIN_BN3 due to: User Location Constraints (PIN_BN3) Info(14709): The constrained I/O pad drives this IPFLUXTOP_UXTOP_WRAP Info(175021): The source IPFLUXTOP_UXTOP_WRAP was placed in location IPFLUXTOPUXTOPWRAP_X185_Y7_N1962 Error(175022): The pin could not be placed in any location to satisfy its connectivity requirements Info(175029): 2 locations affected Info(175029): BL10 Info(175029): pin containing PIN_BL7 I’ve been reading that when the HPS subsystem is enabled, Bank 4A becomes constrained due to shared clocking resources between the HPS and the adjacent transceiver banks, potentially limiting available routing/placement options. Has anyone encountered similar issues when targeting the SFP+ cage or using GTS transceivers on the 4A side with HPS enabled? Any insight or guidance would be greatly appreciated. Thank you!16Views0likes0Comments