currently evaluating FPGA solutions
Dear Intel FPGA Team, Greetings from PARAS Defence and Space Technologies. We are currently evaluating FPGA solutions for our C-band SATCOM terminal project. Our key application requirements are as follows: RF frequency range: 4.4–4.95 GHz • Instantaneous RX bandwidth: 16 MHz • RF channels: 4 RX and 4 TX • Interface: JESD204B/C between the RF transceiver and FPGA • Application: Ground-based SATCOM terminal for tracking a moving aircraft We are considering the Intel Arria 10 FPGA family as a potential platform and have reviewed the available reference design for the ADRV9029 Sub-6 GHz evaluation board with Arria 10 FPGA. To clarify the technical feasibility and plan our development and procurement activities, we would like to arrange a meeting with your FPGA technical and sales teams to discuss the following topics. FPGA Selection and Compatibility Recommendation of a suitable Arria 10 or other Intel FPGA family and specific part number for our application, considering JESD interface requirements, FPGA resources, transceiver capabilities, and future scalability. ADRV9029 JESD204 Integration Confirmation of the supported JESD204B/C configurations, available transceiver lanes, achievable lane rates, and relevant FPGA IP requirements for interfacing with the ADRV9029. Reference Design and Porting Support Guidance on the available ADRV9029–Arria 10 reference design, required hardware platform, design files, software dependencies, and the feasibility of adapting the reference design to our intended FPGA platform. Development Tools and Technical Support Information on the required Intel Quartus Prime software edition, JESD204 IP licensing, simulation resources, design examples, and technical support available during FPGA development. Evaluation Hardware Recommendations for a suitable FPGA development kit or evaluation platform for initial ADRV9029 integration, including availability, compatibility, and procurement options. Product Presentation A technical presentation covering relevant FPGA families, high-speed transceiver capabilities, JESD204 interface solutions, design resources, and application examples suitable for RF and SATCOM systems. Procurement and Commercial Discussion Indicative pricing, product availability, lead times, development kit costs, and long-term supply considerations for prototype development and production. We would appreciate the opportunity to discuss these requirements with your technical specialists and sales representatives at a mutually convenient date and time. Please let us know your availability and whether any additional technical information is required from our side before the meeting. Thank you for your support. We look forward to your recommendations and to working with your team to identify a suitable FPGA solution for our project.
Workaround for TCK frq. limitations on USB-Blaster I/II/III & Clones (fixing "JTAG chain broken")
Workaround for TCK frequency limitations on USB-Blaster I/II/III and clones (fixing "JTAG chain broken") Hi everyone, I'd like to share a practical workaround for a problem many of us run into when programming Altera FPGAs through test fixtures, level shifters or long ribbon cables. **The problem** In these setups, "JTAG chain broken" or "Unable to scan device chain" errors are common. They are usually caused by signal reflections and poor termination on custom boards and long extensions. Lowering the TCK frequency is the standard remedy, but the options are limited: - USB-Blaster I (and most low-cost clones) runs at a fixed TCK of about 6 MHz. Quartus offers no way to change it. - USB-Blaster II can be set to 6/16/24 MHz via `jtagconfig --setparam <cable> JtagClock <freq>`, but nothing below 6 MHz. In practice this setting is also unreliable: it is not persistent and can fall back to the 24 MHz default (see Altera KB: "Why does the TCK frequency setting of the USB-Blaster II download cable revert to the default value of 24 MHz after being changed?"). In our experience it is a constant source of trouble, especially in production where it has to be set again and again. For really marginal lines, 6 MHz is often still too fast. **The workaround** Disclosure: I'm the developer of the tool described below, so please take this as information from the vendor. Quintus Programmer (by Dution) drives the JTAG lines of the USB-Blaster in bit-bang mode instead of using the adapter's fixed shift clock. This lets you choose the TCK frequency freely, e.g. down to 100 kHz, with the same USB-Blaster I/II/III or clones you already have. With a lower TCK, programming and verification become stable again on long or poorly terminated lines without any hardware changes. The standard USB-Blaster driver stays in place, and Quintus only replaces the programming step. **Before reaching for software, check the hardware basics** The recommendations from the Altera Knowledge Base still apply and often fix the problem on their own: - TCK pull-down 1 kΩ to GND, TMS/TDI pull-up 10 kΩ to VCCIO - a small capacitor (10–22 pF) at TCK near the FPGA against ringing edges - a TCK buffer on long or noisy lines If the layout can't be changed, a lower TCK is a practical way out. More info: search for "Quintus Programmer Dution". Happy to answer technical questions here.
Introducing the Altera Community AI Responder — Beta
Altera is introducing the AI Responder, an assistant built into the Altera Community to help provide faster, context-aware guidance for Altera product questions. It uses relevant public Altera documentation and Knowledge Database content, with coverage continuing to expand. The AI Responder may provide source references and can hand off complex or out-of-scope questions to an Altera subject-matter expert. As a beta feature, responses may contain errors or omissions, so please review the sources and verify technical guidance against official Altera documentation before implementation. If the response does not fully address your question, add more context and tag ai_responder to continue the discussion. We welcome your feedback as we improve the Community experience.Cannot program cyclone IV with USB blaster
Hello, I have an Altera Cyclone IV EP4CE6E22C8N board which supports programming via JTAG USB, and so I have a USB blaster revision C and connected it to the JTAG port and installed the drivers for it through the Quartus Prime installer, but unfortunately every time I try to use the programmer with it plugged in, it hangs for a while then prints an error saying "Attempted to access JTAG server -- internal error code 82 occurred", running jtagconfig also says: "Error when scanning hardware - Server error", device manager also shows only USB blaster when as far as I know it should also be showing additional entries such as JTAG interface? I tried different drivers but to the same effect, reinstalling quartus prime and all the drivers, no luck. I also tried running a windows 7 VM and installing quartus prime and the programmer drivers on there in case it was a compatibility issue, but the same happens, server says "server error" and the programmer hangs. I looked in event viewer and the driver appears to be outputting errors: I have also tried to install the drivers manually through the quartus prime 23 install directory. I'm really not sure what to do anymore, hoping someone with more experience can help. Thank you! I am running Windows 11, X86 of course.
Agilex 7 R-Tile PIPE Direct endpoint receives Set_Slot_Power_Limit, but no Config TLPs
Hello, I am developing a custom PCIe endpoint using the Agilex 7 R-Tile PIPE Direct interface. The PHY is provided by the R-Tile IP, while the LTSSM, Data Link Layer, and TLP/DLLP handling are implemented in soft RTL. Environment FPGA: Agilex 7 AGIB027R29A Quartus Prime Pro 24.3.0 Build 212 R-Tile PIPE Direct mode PCIe Gen3 x8 Custom soft LTSSM and Data Link Layer Linux host with a commercial PC/root complex The FPGA is configured before a host cold boot The endpoint is not currently visible in lspci In a successful Signal Tap capture: The LTSSM reaches Gen3 L0. The Data Link Layer reaches DL_ACTIVE. InitFC1 and InitFC2 for Posted, Non-Posted, and Completion traffic are exchanged. We observe valid incoming TLP traffic with a correct LCRC. The host sends a Message TLP that appears to decode as Set_Slot_Power_Limit. No subsequent Configuration Type 0 Read TLP or other expected enumeration TLP is observed. The link later returns from L0 to Recovery.RcvrLock. Our understanding is that Set_Slot_Power_Limit is a posted Message TLP and should not require a Completion TLP from the endpoint. The endpoint should only acknowledge successful reception at the Data Link Layer. Please correct us if this interpretation is wrong. Questions Is receiving Set_Slot_Power_Limit before the first Configuration Read a normal root-port enumeration sequence? Does the endpoint need to respond to this Message TLP in any way other than sending a Data Link Layer ACK? If the ACK DLLP has an incorrect sequence number, CRC, or timing, could the root port stop sending further TLPs and eventually force the link into Recovery? Are there any R-Tile PIPE Direct-specific status or control signals that must be handled before the host starts Configuration transactions? Are there recommended R-Tile debug signals for determining why the root port stops after this message? Could an incorrect Flow Control advertisement—especially Completion Header/Data credits—cause this behavior even if InitFC2 completes? Are there known PERST#, cold-boot, or FPGA-configuration timing requirements for enumeration when using PIPE Direct mode? We are currently capturing the following signals: LTSSM state Data Link Layer state InitFC1/InitFC2 and UpdateFC status Received TLP Fmt/Type and complete header Received TLP sequence number LCRC result ACK/NAK request and transmitted ACK/NAK sequence number Replay timer/replay status RX block lock, CDR lock, and lane numbers Raw 1024-bit PIPE RX block data Any guidance on the expected transaction sequence after Set_Slot_Power_Limit, or additional signals that should be captured, would be greatly appreciated. Thank you.
R-tile CXL base hard IP example for the Agilex 7 M-series Dev Kit (DK_DEV_AGM039EA) does not work
We recently generated an R-tile CXL base hard IP example for the Agilex 7 M-series Dev Kit (DK DEV AGM039EA) with both Quartus Prime Pro 25.3.1 and 26.1. However, the CXL link is always down and stuck at Gen1 2.5Gbps. Do you have any suggestions, or is there a working CXL design example for this kit? We verified that the link functions perfectly with a PCIe Gen5/Gen4 example.We recently generated an R-tile CXL base hard IP example for the Agilex 7 M-series Dev Kit (DK DEV AGM039EA) with both Quartus Prime Pro 25.3.1 and 26.1. However, the CXL link is always down and stuck at Gen1 2.5Gbps. Do you have any suggestions, or is there a working CXL design example for this kit? We verified that the link functions perfectly with a PCIe Gen5/Gen4 example.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-featuresARM 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
