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)
Cyclone 5 first boot linux crashes, howto debug?
Hello, We have a design with a Cyclone V FPGA. Some boards only boot after a reset following power-on. Problem: The Debian Linux with U-Boot boots from the SD card, but after approximately 10 seconds, the system crashes and becomes unresponsive. The login prompt appears (on UART debug), but I cannot enter anything, and the network interface does not work. How should I start troubleshooting? There is a JTAG on the board, but I have never used it until now. Any hints or links would be greatly appreciated. Sorry, but I have no idea how to resolve this, or where to start with the troubleshooting.Inquiry Regarding Cyclone V IBIS Model Definitions and Updates
Dear Intel Support Team, I hope this message finds you well. I am currently conducting IBIS simulations for the Cyclone V FPGA, specifically for the part number 5CGXFC9C6F23, and I have a few questions regarding the IBIS model definitions provided on your official website. Upon reviewing the IBIS file available at the following link: https://www.intel.co.jp/content/www/jp/ja/support/programmable/support-resources/board-layout/ibs-ibis-index.html I noticed that several I/O buffer models appear to have identical definitions despite having different names. For example: "lvcmos_rtpio_d2s1" and "lvcmos_rtpio_d16s1" "lvcmos_rtpio_d2s1_p" and "lvcmos_rtpio_d16s1_p" These models seem to be completely identical in terms of their IBIS definitions, which raises concerns about their accuracy and applicability for simulation purposes. I would like to ask the following: Are there any updated or revised IBIS model files for Cyclone V released after March 20, 2020, which is the last modification date shown on the website? Among the available models, which ones are considered accurate and appropriate for simulation, particularly for the I/O standards listed below? The I/O standards I plan to use are: 3.3V LVCMOS (lvcmos_*) 3.3V LVTTL (lvttl_*) SSTL-135 (sstl135_*) Differential SSTL-135 (dsstl135_*) Your guidance on this matter would be greatly appreciated, as it will help ensure the validity of our signal integrity simulations. Thank you very much for your support. Best regards, Ryusuke YOKOYA
