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
Arria 10 boot from MT25QU01G device failure
Hello , I have a development board which consists of two arria 10 devices that retrieve the configuration from a MICRON MT25QU01G device . Although through the usb blaster seems that i can access the memory using JTAG and SFL and successfully write data in the memory , when the two arria devices boot it seems that there is a configuration error. As referred to the datasheet the first arria is configured in active serial configuration scheme by selecting the appropriate MSEL pins while the other in passive serial . I have also tied the nCONFIG, nSTATUS , DCLK , (AS_DATA_0 and AS_DATA_1) and CONF DONE as referred in pin connection and guidelines. Do you know why the FPGAs are not configured properly ? Regards Manolis
Cyclone V SoC custom board preloader boot sdram test issue
Dear Intel FAE and ALL, This is Brian and having issue on maximum 2GB DDR3 boot sanity test. There is a warning like these: "SDRAM: Running EMIF Diagnostic Test ...Iteration 1734:, expect 0x20a69210 from address 0x20a69213, read 0x20a69210 insteadFailed" But w/o the SDRAM test on preloader, the system can boot into distro and passed memtester. Do the preloader have any bug on the memory size of the SDRAM? It do show a 2048M size message. memtester log: ``` brian@brian:~$ sudo memtester 1900M memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffff000 want 1900MB (1992294400 bytes) got 1900MB (1992294400 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok Loop 2: Stuck Address : setting 3^C ```
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?
