Cyclone VGT Dev Kit boards - some new boards failing to boot from NOR Flash
We've been using these boards for years, having certified them for use in one of our products. In the last few months we have now received 5 of these boards and they fail to configure from NOR flash. These are all the new Rev B CVGT Dev Kit edition. Not all of the new RevB fail, but the fail rate is high, getting close to 50%. Yes, we know they changed to a Micron NOR flash for Rev B and rerouted some data lines, we are using the new RevB MAX5 files and have updated the Cyclone V NOR flash pins to match as well. I made some diagnostic changes to the MAX5 boot source (I set the PGM leds to count retries) and discovered that on the bad boards, the boot process goes through multiple configuration retries and eventually the watchdog timer fires, turns on the ERR (D5) red LED and stops. With the factory image they come with, there are also dozens of retries, then sometimes the boards fail, sometimes they boot up. With the slow speed that the NOR flash configuration runs at, there is no reason that it should ever fail and retry, and indeed on good boards they configure the first time every time with no retries. The first four we were able to send back to Altera (Via digikey where we bought them). We just got another bad one yesterday, this one from Mouser. Has anyone else seen this issue, and/or heard from Altera about this? Board link: https://docs.altera.com/r/docs/792833/current/cyclone-v-gt-fpga-development-kit-user-guide/kit-features
JTAG pins order for USB Blaster III - 1.27" header
USB Blaster III header has shrined in size relatively to the previous JTAG cables. I see that in addition, pinout order has changed(according to USB Blaster III user guide). So, if I want to place on a new board that I'm developing a matching connector(pitch=1.27") for USB Blaster III (without using the adapter board from the KIT), then I have to use new pinout order: 1-VCC_TRGET, 2-TMS, 3-GND, 4-TCK, 6-TDO, 7-nTRST, 8-TDI, 9-GND, 10-nPROCRST. This order is different then was used with previous JTAG cables. I couldn't find any reference schematic(also of EVAL KITs) that supports this new JTAG order. I will appreciate if anyone from the forum can confirm my observation. If it's possible that someone can answer me with an existing working reference design with 1.27" connector, I will appreciate it more.
ARM DS5 debugger Access/Detection of CM55 on Agilex5 fpga device
Hi Team, We recently purchased license for the ARM DS5 IDE from Altera with License file contains note as NOTICE="For use with Intel or Altera devices only". I am using Arm Development studio IDE with version 2025.1-1. ALtera Agilex 5 FPGA device configured with custom soft macro based design which is only having ARM Cortex M55 processor cores with coresight debug IP . My question is whether ARM DS IDE will detect, access and debug the Cortex M55 cores which is in the fpga through the JTAG USB Blaster ? Please provide the detailed explanation Regards Suresh
Fitter error in A5ED043AB23AI2V Example design
Hi, I have tried using the example design of the A5ED065BB32AE4SR0 development kit and modified the part number to A5ED043AB23AI2V. During compilation, I am encountering a fitter error when both PCIe and USB 3.1 are enabled together. However, I am able to compile successfully when using each interface individually. Could you please help me understand how to resolve this issue?Verifying R-Tile PIPE Direct x8 lane-to-pin mapping on Agilex 7 I-Series Dev Kit
Hi all, I am bringing up a custom PCIe Gen5 controller on the Intel Agilex 7 I-Series Development Kit using the R-Tile Hard IP in PIPE Direct mode (1×16 bundle, only Octet 0 / lanes 0–7 active for now). The soft logic above PIPE (LTSSM, TX TS1/TS2 generation, RX word aligner, 8b/10b decode) is custom RTL. Symptom During Polling.Active, only 2 of 8 lanes ever reach wa_locked = 1 in my soft K28.5-comma word aligner. The other 6 lanes stay in SEARCH/VERIFY indefinitely. The 2 locking lanes are not always the same pair across resets, which makes me suspect either (a) a per-lane CDR / rx_valid gating issue, or (b) a lane-to-pin mapping mismatch between my QSF and the actual PCIe edge connector routing on the dev kit. Before I dig deeper into the CDR / rxdatavalid side, I would like to sanity-check the pin assignments below against the official Agilex 7 I-Series Dev Kit schematic / pin-out, because if lanes are physically swapped vs. what the host RC expects, only the lanes that happen to land on lane 0 (and possibly its mirror) would ever see TS1 ordered sets. Pin assignments in pipe_direct.qsf (Octet 0, lanes 0–7) Signal Pin Signal Pin refclk0 DR68 refclk1 CU68 pin_perst_n CD58 tx_p_out0 / tx_n_out0 DL74 / DH73 rx_p_in0 / rx_n_in0 DE82 / DB83 tx_p_out1 / tx_n_out1 DB77 / DE76 rx_p_in1 / rx_n_in1 CW80 / CT79 tx_p_out2 / tx_n_out2 CW74 / CT73 rx_p_in2 / rx_n_in2 CM82 / CJ83 tx_p_out3 / tx_n_out3 CJ77 / CM76 rx_p_in3 / rx_n_in3 CF80 / CC79 tx_p_out4 / tx_n_out4 CF74 / CC73 rx_p_in4 / rx_n_in4 BY82 / BU83 tx_p_out5 / tx_n_out5 BU77 / BY76 rx_p_in5 / rx_n_in5 BP80 / BL79 tx_p_out6 / tx_n_out6 BP74 / BL73 rx_p_in6 / rx_n_in6 BH82 / BE83 tx_p_out7 / tx_n_out7 BE77 / BH76 rx_p_in7 / rx_n_in7 BB80 / AW79 IO standards: HCSL for refclk0/1, HIGH SPEED DIFFERENTIAL I/O for all TX/RX, 1.0V for pin_perst_n. Lanes 8–15 (Octet 1) are assigned in the QSF as well but are intentionally excluded from the active datapath in this build. Specific questions Are the lane 0–7 TX/RX pin numbers above the correct mapping for the PCIe edge connector on the Agilex 7 I-Series Dev Kit when the R-Tile is configured as a PIPE Direct 1×16 bundle and only the lower octet is used as a x8 link? For PIPE Direct 1×16 with Octet 0 active, is refclk0 (PIN_DR68) the correct refclk source, or does the bundle require both refclk0 and refclk1 driven from the same 100 MHz source even though only 8 lanes are used? Are there any lane-reversal / polarity-inversion considerations on this dev kit that I would need to handle in soft logic vs. inside the R-Tile IP (i.e. does the IP already account for board-level lane reversal so that lane 0 in RTL is guaranteed to be lane 0 at the connector)? Any pointer to the authoritative pin-out table for this board's PCIe edge connector would be very helpful. Thanks!Stratix 10 GX SI Board - issue with the Board Test System (BTS)
We recently purchased several Stratix 10 GX Signal Integrity development boards and would appreciate your advice regarding an issue with the Board Test System (BTS). When attempting to program the FPGA using the .sof files available under the Configure tab in BTS, none of the designs can be successfully programmed. The system consistently reports: “Detected bts_config.sof on FPGA.” It appears that the FPGA remains running the default bts_config.sof, and the selected configurations do not load as expected. This happens when the Quartus version in the QUARTUS_ROOTDIR is the Quartus standard. If I change it to Quartus Pro version ( I tried 22.1 24.1 and 25.1), the BTS will not be open, and it gets stuck at "Setup connection to System Console server". Could you please let us know whether this is a known issue and advise on how to resolve it? I think it might be related to the version of Quartus we use. If so, please can you suggest which latest version we should use for the BTS? Thank you very much for your assistance. Best regards, Toni771
The old NIOS development kit, Stratix edition: factory demo image.
I have some of the boards, but one of them isn't able to run the demo code, there are no blinking LEDs. Moreover, the factory demo images of both NIOSII EDS 5.1 and 7.0 didn't work, that's funny. After reading back flash from one of the boards, the backup factory demo image worked as expected. But one other board is still not able to run code, stay in an ambiguous state (CPU reset state?), factory safe LED lights. Are there some things to check by the factory demo image? Why does it hold on running the factory demo code? SDRAM failure? The user bitstream (no NIOS II) is OK to run from the flash.MAX10 10M50 Development KIT Triple Speed Ethernet problem
Greetings to all of the ALTERA Experts, I have been trying to get a Gigabit Ethernet interface working on an ALTERA MAX10 10M50-C Development kit and keep hitting a bit of a brick wall when tying to communicate with the MARVEL ALASKA 88E1111 PHY. It does not appear to respond correctly when i try to read for example the PHY ID register (address x02) which should respond with the value 0x041 but instead sends back 0x7fff. I am using a System Verilog HDL approach to both instantiate the ALTERA Triple speed IP core in MAC only mode, with 2K word FIFOs, and full duplex 10/100/1000. The IP is set to work in Gigabit mode. When i connect the board to a windows 10 PC using an Ethernet cable i can see the Yellow LED lit up on the Dev KITS PHY connector and when i test the connection on the windows 10 PC it says it is up and connected. But when i try to send any Ethernet packets (i am using IPV4 + UDP as packet payload) nothing gets through to the PC. I have verified this as well using WIRESHARK which shows me no ethernet frames are coming in from the MAX10 Dev kits end. I have set the Triple speed Ethernet IP cores mac0/mac1 register to this random value: 48'h321C23174ACB I think this is OK and what the Triple Speed Ethernet User Guide says. Please correct me if my thinking is wrong though ? Questions: a) Does any body know of any errata / bugs with this Development KIT OR with the MARVELL PHY ? b) Can anybody point me to a Git Hub which has a known working example using this ALTERA Dev Kit along with this MARVELL PHY ? This can use either a HDL approach (like i am trying to use here) or a NIOSV softcore processor approach. c) The MAX10 Dev Kit has 2 Ethernet PHYS. A and B. I think that the MAX10 10M50-C Dev Kit sets its A MARVELL PHY Address to 0x0 and its B side MARVELL PHY Address to 0x1 BUT its not easy i found to figure out the PHY addresses. If somebody can please show me how to properly derive the PHY ADDRESSES for both the MARVELL 88E1111 devices for PHY A (ETHERNET A) and PHY B (ETHERNET B) on the MAX10 10M50-C Dev Kit Board Schematic) i will be very grateful ! Thanks for any help, Dr Barry H
