Stratix 10 FPGA Dev Kit VCCIO_FMC voltage issue
The FMC VCC IO voltage level is adjustable using a resistor on the board as shown below. The default is 1.8V and that works fine. When I depopulate the resistor (R468) to get 1.2V, the output voltage goes to 0V and the enable line for the DC-DC converter also goes low. Any idea what the reason for this is? And what is the fix?
Does the FPGA N3000 support OpenCL and OneApi?
I received an INTEL FPGA PAC N3000 card, and taking the opportunity, I decided to learn how to develop with SYCL and oneAPI. However, I ran into problems. I fully installed the FPGA PAC N3000 Acceleration Stacks v1.3.1 and also updated the board's BMC from D.1.0.12 to D.2.0.19. Then I started configuring oneAPI 2022 using intel-basekit and fpga-addon, but proper configuration requires bsp, and I couldn't find it anywhere. I also saw that on the website page for Quartus Prime Pro 19.2, which is installed with IAS 1.3.1, there's a tab with oneAPI and BSPs for boards. I looked at other versions, but I only found mentions of Arria 10-GX and Arria 10-SX. I'm not sure if this will help, but the log is from CentOS 7.6.1810. [root@node-fpga ~]# fpgainfo fme Board Management Controller, MAX10 NIOS FW version D.2.0.19 Board Management Controller, MAX10 Build version D.2.0.6 //****** FME ******// Object Id : 0xF300000 PCIe s:b:d.f : 0000:84:00.0 Device Id : 0x0b30 Numa Node : 1 Ports Num : 01 Bitstream Id : 0x23000110010309 Bitstream Version : 0.2.3 Pr Interface Id : f3c99413-5081-4aad-bced-07eb84a6d0bb Boot Page : user [root@node-fpga ~]# fpgainfo bmc Board Management Controller, MAX10 NIOS FW version D.2.0.19 Board Management Controller, MAX10 Build version D.2.0.6 //****** BMC SENSORS ******// Object Id : 0xF300000 PCIe s:b:d.f : 0000:84:00.0 Device Id : 0x0b30 Numa Node : 1 Ports Num : 01 Bitstream Id : 0x23000110010309 Bitstream Version : 0.2.3 Pr Interface Id : f3c99413-5081-4aad-bced-07eb84a6d0bb ( 1) Board Power : 59.65 Watts ( 2) 12V Backplane Current : 2.91 Amps ( 3) 12V Backplane Voltage : 11.92 Volts ( 4) 1.2V Voltage : 1.20 Volts ( 6) 1.8V Voltage : 1.80 Volts ( 8) 3.3V Voltage : 3.27 Volts (10) FPGA Core Voltage : 0.90 Volts (11) FPGA Core Current : 14.47 Amps (12) FPGA Core Temperature : 62.50 Celsius (13) Board Temperature : 42.00 Celsius (14) QSFP A Voltage : N/A (15) QSFP A Temperature : N/A (24) 12V AUX Current : 2.08 Amps (25) 12V AUX Voltage : 11.97 Volts (37) QSFP B Voltage : N/A (38) QSFP B Temperature : N/A (44) Retimer A Core Temperature : 63.00 Celsius (45) Retimer A Serdes Temperature : 64.00 Celsius (46) Retimer B Core Temperature : 0.00 Celsius (47) Retimer B Serdes Temperature : 0.00 Celsius [root@node-fpga ~]# aoc -list-boards Board list: pac_a10 (default) Board Package: /opt/intel/oneapi/compiler/2022.2.1/linux/lib/oclfpga/board/intel_a10gx_pac pac_s10 Board Package: /opt/intel/oneapi/compiler/2022.2.1/linux/lib/oclfpga/board/intel_s10sx_pac pac_s10_usm Board Package: /opt/intel/oneapi/compiler/2022.2.1/linux/lib/oclfpga/board/intel_s10sx_pac Memories: device, host [root@node-fpga ~]# aocl list-devices -------------------------------------------------------------------- Device Name: acl0 BSP Install Location: /opt/intel/oneapi/compiler/2022.2.1/linux/lib/oclfpga/board/intel_a10gx_pac Vendor: Intel Corp Physical Dev Name Status Information pac_f200000 Uninitialized OpenCL BSP not loaded. Must load BSP using command: 'aocl program <device_name> <aocx_file>' before running OpenCL programs using this device DIAGNOSTIC_PASSED -------------------------------------------------------------------- [root@node-fpga ~]# aocl initialize acl0 pac_a10 aocl initialize: Running initialize from /opt/intel/oneapi/compiler/2022.2.1/linux/lib/oclfpga/board/intel_a10gx_pac/linux64/libexec bitstream.c:391:validate_bitstream_metadata() **ERROR** : Interface ID check failed Error writing bitstream to FPGA: invalid parameter Error programming device aocl initialize: Program failed. [root@node-fpga ~]#
EPM9320LI84-20
Hello! Could you please clarify something? Within the same batch of EPM9320LI84-20 FPGAs, the marking quality varies significantly, which is especially noticeable in the letter A in the ALTERA logo. This is not an isolated case within the batch—there are several chips with the same issue. Could this happen during manufacturing? As you understand, these chips were discontinued long ago and are no longer available from official distributors, so we have to source them from less reliable suppliers. Please respond as soon as possible. Thank you!
Process for RMA - Agilex 7 FPGA I-Series Transceiver Development Kit (6x F-Tile)
Hello there, I have an Agilex™ 7 FPGA I-Series Transceiver Development Kit (6x F-Tile) (https://www.altera.com/products/devkit/a1jui0000049utomam/agilex-7-fpga-i-series-transceiver-development-kit-6x-f-tile) that has recently stopped functioning correctly. In particular, the JTAG chain does recognize the existence of the Agilex FPGA. Quartus's JTAG debugger throws an error: Error: TDI connection to the first detected device 10M16S(A|C|L) might be shorted to GND Error: The TCK and TMS connections to the device before the first detected device 10M16S(A|C|L) might have a problem Info: Detected 1 device(s) Info: Device 1: 10M16S(A|C|L) When trying different settings on the JTAG chain selection mux, it is clear that the System MAX10 is detected and functioning correctly, but the Agilex FPGA cannot be detected. We have tried to reprogram the MAX10 with the factory default image, but there has been no change. We suspect a hardware issue with the JTAG chain. At this point, the Agilex FPGA is not accesible, rendering the board unusable for our purpose. Could ALTERA please support us on this? Is it possible to start the process for an RMA? Are there any options that we can consider? We greatly appreciate your assistance in this time of need Thank you
Agilex 3 AVST programming fails
Hi, We are trying to program an Agilex 3 device over the AVST8 interface, implemented through a CPU using SPI and bit-banging. Setup (see picture below): Data is shifted into a serial-to-parallel converter via SPI. AVST_CLK is generated from the SPI CS signal. AVST_VALID and AVST_READY are controlled by GPIOs. With this setup, we can mimic the passive serial programming approach used on Arria FPGAs. What works: Programming and testing over JTAG works fine. The FPGA design itself runs correctly. What does not work: During AVST8 programming, AVST_READY goes low after ~8210 bytes and never returns high. Programming sequence we follow: CPU initializes pins: nCONFIG=0, AVST_VALID=0 CPU sets nCONFIG=1 FPGA pulls nSTATUS=0 CPU sets nCONFIG=0 FPGA sets nSTATUS=1 CPU provides some clock cycles (~81 cycles) on AVST_CLK (since AVST_READY is low) FPGA sets AVST_READY=1 CPU sets AVST_VALID=1 and streams configuration data After 8210 cycles, FPGA sets AVST_READY=0 CPU sets AVST_VALID=0 and continues clocking At this point, AVST_READY never goes high again. What we observed: If we deliberately corrupt the configuration data, nSTATUS goes low after a few cycles — as expected. This suggests that the FPGA is checking data integrity, but something prevents AVST_READY from recovering. Our bit-banged AVST_CLK frequency is only about 60 kHz. Could this low frequency be the root cause? Question: Why does AVST_READY stay low after 8210 bytes? Is the slow clock (60 kHz) causing the issue, or are we missing something in the programming sequence? Thanks in advance for your support!10AS032H2F34I2LG SPI1 master controller to TPM SLB9672 SPI communication
Intel Community Case Issue description Short background As drawn in schematics, Intel Arria10 soc P/N 10AS032H2F34I2LG SPI1 master controller pins are connected to Infineon TPM P/N SLB9672AU20FW1613XTM. The SOC SPI module 1 master controller at base address @FFDA5000 communicates with the TPM in SPI communication mode 0. In addition, to ensure the correct initialization of the TPM, HPS shared GPIOs GPIO1_io7 (Q3_8) and GPIO1_io8 (Q3_9) are connected from SOC to TPM as reset_n and interrupt_n signals respectively. The problem Attached boot pwr up log.txt describes this issue as seen at the HPS UART. The SPIM1 controller in base address FFDA5000 is probed and mapped in SDRAM ( for example seen by cat /proc/iomem), but TPM is not probed neither in u-boot stage while writing CLI command "tpm2 init" nor during kernel loading, so /dev/tpm device driver isn't opened. It assumed that the problem occurs due to CS signals toggles from LOW to HIGH every data byte instead of staying LOW for the whole 4 bytes header message sent on MOSI (we wait for TPM to responds "ready" by update tpmEstablishment bit 0 in the TPM_ACCESS_0 register ). This toggle might stuck/reset the TPM state machine. We encountered the same issue at all cards (not a singular issue). Furthermore, released working custom design consist of Xilinx MPSOC project, connected to the same TPM P/N with same connectivity. sources u-boot version: socfpga_v2024.07 from altera github opensource Kernel version: socfpga-6.6.51-lts File system ubuntu 22.04.5 LTS from ubuntu center. What checked? Board Design HW HW connectivity validation : schematics attached ( U33 to U42 connections) Pins from SOC to TPM are connected correctly according to intel document, where a formal table for the relevant SOC (F34 tab) describes Q3_1 to Q3_4 pins functionality ( F20, G20, E18, E17 😞 PCB and its assembly (signals connectivity between SOC and TPM, resistors value, voltages level to TPM and SOC bank) checked by flux according to schematics and based on TPM datasheet. HPS Pins are mapped and connected correctly. Pins direction and voltage bank level are correct. SLB9672FW16 TPM PIN CONNECTION# ACTUAL FUNCTIONALITY SELECTION SOC SHARED I/O SOC HW PIN 19 CLK SCLK Q3_1 E17 21 MOSI MOSI Q3_2 E18 24 MISO MISO Q3_3 G20 20 CS0_n SS0_N Q3_4 F20 17 Reset_n GPIO1:io6 Q3_7 F19 18 INT_n GPIO1:io7 Q3_8 E19 FW: QUARTUS 24.03 PRIME PRO tool At HPS QSYS there is a full compliance to the above described pins connectivity table and the expected functionality (Q3_1-Q3_4 , Q3_8 and Q3_9): Pin Assignment file output produced by Quartus 24.3 prime pro, correct as expected: U-BOOT 2024.07 HANDOFF between Quartus to U-BOOT device tree relevant pins are configured and mapped correctly according to Intel® Arria® 10 HPS Register Address Map and Definitions document. Each shared i/o selection value of SPIM1 controller is: 3 as required, for example : in handoff file and its include header: <0x00000060 PINMUX_SHARED_IO_Q3_1_SEL>, <0x00000064 PINMUX_SHARED_IO_Q3_2_SEL>, <0x00000068 PINMUX_SHARED_IO_Q3_3_SEL>, <0x0000006c PINMUX_SHARED_IO_Q3_4_SEL>, my_handoff_qspi_h.txt: #define PINMUX_SHARED_IO_Q3_1_SEL 3 #define PINMUX_SHARED_IO_Q3_2_SEL 3 #define PINMUX_SHARED_IO_Q3_3_SEL 3 #define PINMUX_SHARED_IO_Q3_4_SEL 3 This indicates that these pins are configured for SPIM1 (SPI Master 1), which aligns with your note that the TPM is connected via spim1 @ 0xffda5000. In addition, the PINMUX_SPIM1_USEFPGA_SEL is set to 0, which means HPS is using SPIM1, not FPGA: #define PINMUX_SPIM1_USEFPGA_SEL 0 The relevant 4 consecutive address registers that corresponded to the SPI functionality and selected by pin mux were correctly read from physical memory : Each shared i/o selection value of SPIM1 controller is: 3 as required for correct pin functionality. u-boot .config SPI & DRIVER enabled: CONFIG_DESIGNWARE_SPI=y ( with ALTERA_SPI=y get the same bottom line and waveforms). CONFIG_SPL_DM_SPI=y CONFIG_SPL_SPI=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_SPI_MEM=y CONFIG_CMD_SPI=y CONFIG_DEFAULT_SPI_BUS=1 CONFIG_DEFAULT_SPI_MODE=0x0 ( correlated to TPM SPI mode :0 only) TPM support is enabled: CONFIG_TPM=y CONFIG_TPM_V2=y CONFIG_TPM2_TIS_SPI=y CONFIG_CMD_TPM=y CONFIG_CMD_TPM_V2=y socfpga_arria10_socdk_dtsi &spi1 { status = "okay"; num-cs = <1>; #address-cells=<1>; #size-cells=<0>; u-boot,dm-pre-reloc; tpm@0 { compatible = "tcg,tpm_tis-spi"; reg = <0>; //cs 0 spi-max-frequency = <1000000>; //for init reset-gpios = <&portb 6 GPIO_ACTIVE_LOW>; }; }; DTC -I DTS -O spi@ffda5000 { compatible = "snps,dw-apb-ssi-3.23a\0snps,dw-apb-ssi"; #address-cells = <0x01>; #size-cells = <0x00>; reg = <0xffda5000 0x100>; interrupts = <0x00 0x66 0x04>; num-cs = <0x01>; tx-dma-channel = <0x1f 0x10>; rx-dma-channel = <0x1f 0x11>; clocks = <0x1e>; resets = <0x04 0x32>; status = "okay"; u-boot,dm-pre-reloc; tpm@0 { compatible = "tcg,tpm_tis-spi"; reg = <0x00>; spi-max-frequency = <0xf4240>; reset-gpios = <0x20 0x06 0x01>; }; }; Debug signals with driver high log level and scope During boot when stop during u-boot countdown I see the boot messages(highest log level for SPL and u-boot): It seems the SPI master controller binds the TPM with CS0 as expected. Dm tree command in CLI also supports it: Dm drivers command in CLI also supports it: Driver uid uclass Devices ---------------------------------------------------------- dw_spi 114 spi spi@ffda5000 tpm_tis_spi 124 tpm tpm@0 I added sone debug prints to understand the line where stuck. The gpio reset occurred during the u-boot while using tpm2_tis_spi.c driver With" tpm2 init" CLI command: The reset signal toggles to '0' and back to '1' and complies minimal pulse width and timing specifications. In log I get print lines that describe the proceeding sequence in the u-boot driver: I get probe error in any sspi or tpm command , the same sequence occurs: Reset signal toggles correctly (probing the relevant gpio-reset). According driver correlated to tis spi specifications 1.3 version, we send correct data as hard coded described in the driver and complies to the specifications: 0x80= '1000 0000' means read 1 byte from address 0x0: 0xD4 is an offset described in the specification: 0x00 and 0x00 assemble the TPM ACESS locality 0 register to sample from TPM ready bit: In scope or logic analyzer I see the same pictures, the key: Green-CS0 Blue-MOSI Yellow- SCLK (500KHz as required for initialize). PINK- MISO(last picture) 0x80 means read 1 byte from address 0x0. 0xd4 offset required 0x00 as sent twice(I attached only this picture. 0x00 twice in a row is the same picture in scope) Because TPM ready doesn’t rise to '1', I proceed to wait state and send 0XFF in MOSI blue signal till timeout arrives because MISO stays LOW and ready bit sampled is '0' always as also described in the log below: Zoom out , all 4 CS toggle cycles for the 4 bytes are seen: It seems the problem is that the CS signals toggles to HIGH every byte instead of staying LOW for the whole 32 bits message of the SPI header till TPM responds it is ready and update tpmEstablishment bit 0 in the ACCESS register : According to the specifications, page 102 the signals drawn as CS should stay LOW and support this assumption: The driver toggles CS every SPI MOSI 8 bits/clock cycles and the TPM state machine is stuck. How can we solve it and update the u-boot and linux drivers so the CS staying LOW for the whole transaction?
Agilex™ 5 FPGA E-Series 065B Premium Development
I am using Agilex™ 5 FPGA E-Series 065B Premium Development and For my project I required 491.52 MHz clock. when I checked the schematic of the development board,one 153.6 MHz differential clock available and from this clock i can able to create 491.52 MHz. But when I used this clock iam getting some error like, Illegal constraint of I/O pad to the location Can anybody explain how the way I can use this clock.
Documents for "pinout", electrical and thermal specifications (635218_001_Ballout.xlsx, 635218_001_E
Hello everyone, I would like to find the documents for the "pinout", electrical and thermal characteristics of the Intel 500 series chipset. I tried to find it in the document "Intel® 500 Series Chipset Family Platform Controller Hub Dataset, Volume 1 of 2 " but there was only an indication of where to look for approximately and by what name, but unfortunately I did not find anything. I hope that someone will help)
