Recent Content
NIOS-V QSYS Warning Properties (associatedClock) have been set on
Hello, I have a really basic setup of a NIOS V system, but get Warnings in QSYS (using Quartus 25.1 Standard) about Properties of associatedClock: System: Warning: Warning: nios_subsystem.intel_niosv_m_0: Properties (associatedClock) have been set on interface reset - in composed mode these are ignored Warning: nios_subsystem.intel_niosv_m_0: Properties (associatedClock,associatedReset) have been set on interface instruction_manager - in composed mode these are ignored Warning: nios_subsystem.intel_niosv_m_0: Properties (associatedClock,associatedReset) have been set on interface data_manager - in composed mode these are ignored Questions: What is "composed mode" and how can I control it? There is no NIOS Parameter associated with it This appears in a basic setup simply by adding NIOS V to the system. How do I get rid of this warning? best regards Fabian
starting to learn FPGAs
Hello everyone, I want to start learning FPGA development on my own. My operating system is Linux.Could you please tell me what software/tools I need to download to begin? Do I need a hardware programmer or a specific board? I’m a beginner, so I’d appreciate any advice on the easiest setup.MCTP over PCIe VDM routing to PMCI in OFS N6000 FIM configuration and datapath clarification
Hi Team, I am working on implementing PLDM over MCTP over PCIe VDM on the Intel N6000 platform OFS PCIe Attach FIM. I have referred the following documents: 1. OFS Linux MCTP driver documentation: https://github.com/OFS/linux-dfl/blob/2014c95afecee3e76ca4a56956a936e23283f05b/Documentation/networking/mctp.rst 2. OFS Agilex PCIe Attach FIM architecture guide: https://ofs.github.io/ofs-2025.1-1/hw/n6001/dev_guides/fim_dev/ug_dev_fim_ofs_n6001/#1211-top-level From my understanding, the PMCI module inside the FIM contains the MCTP over VDM controller which transmits MCTP payloads containing PLDM commands to the MAX10 BMC. The BMC communicates with PMCI via SPI. The host can access PMCI CSRs through PCIe MMIO and this is working in our setup using the intel-m10-bmc driver. However, the datapath for MCTP over PCIe VDM from the host is unclear. I have the following questions: 1. How are PCIe VDM packets generated from the host routed to the PMCI MCTP controller inside the FIM? 2. Is there any specific configuration or enablement required in the PCIe subsystem or FIM fabric to allow VDM packets to reach PMCI? 3. What is the role of the MCTP Management Interface or MCTP VDM controller IP in the OFS FIM design? 4. Is this a custom IP responsible for filtering or routing VDM packets? How is this block exposed to the host? 5. Are there any registers, BAR mappings, or configuration steps required to enable this datapath? Does the Linux MCTP stack directly interact with PMCI, or is routing handled entirely in hardware? Currently, we are able to generate PCIe VDM packets from the host, but they are not observed at the PMCI or BMC side. This suggests that the ingress path may not be enabled or packets are being filtered before reaching PMCI. Any clarification on the expected datapath and required configuration for enabling host to PCIe VDM to PMCI to BMC communication would be very helpful. Thanks and regards, Nafiah Siddiqha
Agilex 5 A5ED043AB23AI2V with pcie and usb 3.1 design issue
Hi, I took the design for the dev kit example design with the device (A5ED065BB32AE4SR0) for PCIe Gen4 x4 and HPS USB 3.1, and I changed the part number to A5ED043AB23AI2V and upgraded the required IPs and started the compilation. I am getting the error... I attached it. I thought this was due to the difference in package B32 vs. B23. For the B23 package, it only has 4c for PCIe and 1c for HPS USB 3.1. For B32, it has 4c and 4b banks also for PCIe and 1c for HPS USB 3.1. Does my part number support the req design with both PCIe Gen4 x4 and HPS USB 3.1? Because individually it is compiling; if not, why...? What is the reason...? If it supports where I am getting wrong. Please help me. Thank youRequest: Questa Intel FPGA Starter Edition License for Quartus Prime 25.1 (Windows 11)
Hello, I would like to request a Questa Intel FPGA Starter Edition license for my Windows 11 environment. ■ Target Tool - Questa Intel FPGA Starter Edition - Version: 25.1 Standard Edition (bundled with Quartus Prime 25.1) ■ Environment - OS: Windows 11 (Ryzen laptop) - Quartus Prime 25.1 Standard Edition installed - WSL2 installed - No floating license server (local node-locked license required) ■ HOSTID (MAC Address) My machine uses a Realtek Ethernet adapter that remains “enabled” even when the cable is disconnected. Therefore, Questa detects this Ethernet NIC as the primary physical adapter. HOSTID (Ethernet MAC): **16-09-01-1E-94-24** ■ Additional Notes - Wi-Fi is also available, but Questa always selects the Ethernet NIC first. - I confirmed the MAC address using: - `getmac /v /fo list` - `ipconfig /all` - Please generate a node-locked license file (questa_lic.dat) for this HOSTID. Thank you very much for your support.Issues with downloading
Im currently trying to download intel Quartus version 24.1 (recommended via the university), however im getting an error which ive added in the attachment below. I am on my home WiFi which is a private network and my laptop has no firewall or antivirus apart from windows defender active. Ive had this issue on multiple different internet connections and im wondering if anyone has any advice on how i can fix it.Timing Slacks inside Altera IP
Hi, I am compiling my design for the device 10AX115N2F40I2SG using: Quartus Version: 22.1std.2 (Build 922, 07/20/2023, Standard Edition) I am encountering timing violations (negative slack) on the clock a10_internal_oscillator_clock0 across all synthesis seeds. Due to these violations, I am unable to close timing on my design. From my analysis, the failing paths appear to be internal to the Intel (Altera) IP, for example: From: ddr3_phy_wrapper48:ALTERA_DDR.ddr3_phy_wrapper_u|se_phy_master:u_qm2_phy|se_phy_master_altera_emif_221_zihdyxy:emif_0|se_phy_master_altera_emif_arch_nf_221_lnlpemi:arch|se_phy_master_altera_emif_arch_nf_221_lnlpemi_top:arch_inst|altera_emif_arch_nf_pll:pll_inst|iopll_bootstrap:gen_pll_dprio.inst_iopll_bootstrap|gen_pll_dprio.r_dprio_writedata_in_use~RTM To: |ddr3_phy_wrapper48:ALTERA_DDR.ddr3_phy_wrapper_u|se_phy_master:u_qm2_phy|se_phy_master_altera_emif_221_zihdyxy:emif_0|se_phy_master_altera_emif_arch_nf_221_lnlpemi:arch|se_phy_master_altera_emif_arch_nf_221_lnlpemi_top:arch_inst|altera_emif_arch_nf_pll:pll_inst|pll_inst~dprio_reg My understanding is that this clock is only active during PLL calibration at device power-up and is not used during normal functional operation. Given this, I would like to confirm whether it is safe and appropriate to constrain these paths as false paths. For example: "set_false_path -from [get_clocks {a10_internal_oscillator_clock0}]" Could you please advise if this approach is valid, or if there is a recommended way to properly constrain these paths? I attached an image of the slacks.
