Unique ID registers in Cyclone V
Hello everyone, I need to uniquely identify individual devices at runtime from the HPS (ARM Cortex-A9) side. Does the HPS side of the Cyclone V SoC have any built-in unique ID registers, such as: - A hardware serial number - A unique device ID - OTP (One-Time Programmable) fuses with unique identifiers - Any factory-programmed identification values What I've Tried: I've reviewed the Cyclone V documentation but haven't found clear information about unique ID registers accessible from the HPS side (unlike some other ARM SoCs that have dedicated UID registers). However I have seen Unique ID present in the FPGA side (https://www.intel.com/content/www/us/en/docs/programmable/683336/20-3/cores-user-guide.html), but this is not useful for my use case. Any guidance, documentation references, or code examples would be greatly appreciated! Thanks in advance!
Routing PL DDR to PS
We have an Arria 10 board with bad traces between the DDR memory and the hard memory controller for the PS. The PL has additional DDR memory not connected to the PS that works fine. Does a workaround exist that allows us to route the DDR memory connected to the PL and use it for Linux on the PS?
SDRAM calibration failed.
Hello, after Enpirion stopped selling some of the parts we used on our board, we had to redesign it. We assembled ten boards, and on two of them, I’m now getting an SDRAM calibration error in U-Boot. I’d like to enable the SDRAM calibration report to understand the cause of the error. However, the described method of adding. #define RUNTIME_CAL_REPORT 1 in the sequencer_defines.h file didn’t work. I generated the files using the QTS filter script, but there was no change. Could you please tell me how to properly enable the SDRAM calibration report so I can debug the issue?
Cyclone V HPS FPGA2SDRAM Clock Queries
Dear Intel and all, Having some very puzzling behavior on HPS SDRAM and FPGA fabric bridge. If a fast clock i.e. 148MHz is running on 128bit AXI3 aka f2h_sdram0 mostly read action. And another AXI3 is using the remain 128bit bus with 144MHz aka f2h_sdram1 mostly on write. As such the system will stuck on distro aka Linux. With all these background could engineer or internal stuffs help. What is the restriction or constraints to use these bus under safe and stable speed? Forgot to provide stable situation: If the write dominated bus is reduced to 100MHz then the system is stable and no stall is found. So this makes a very strong feeling that the write cache is having issue? maybe CMA insufficient? Brian
High-Latency Ethernet on Arria 10 SoC device using HPS EMAC and KSZ9031
Hello, I observe a strange issue using the 1Gbps Ethernet on the Arria 10 SoC HPS. I observe the issue on our custom board and also on the Arria 10 Dev Kit. For simpler debugging, explanation and potential reproducibility, I focus now on the Dev Kit: https://www.intel.com/content/www/us/en/products/details/fpga/development-kits/arria/10-sx.html I built the Kernel 6.6 for the development board and use the tool `iperf3` for an Ethernet stress test. The setup is simple: Direct connection from the DevKit to a Computer. On the Dev Kit I start the "Server" with `iperf3 -s` and on the PC side, I call the client in bidirectional mode like this: `iperf3 -c <IP> --bidir`. In parallel I start a ping on my PC console to observe the Ethernet latency. Every now and than, the ping latency increase to 500-1000ms (after the iperf3 test has finished and no data transfer is done). It is really sporadic and doesn't happen every time. But it is some how a big issue on our product using the Arria 10 device. I think it is some how related with an old observation: https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/is-there-a-bug-in-the-Ethernet-MAC-of-Arria10-SoC-devices/m-p/1238772#M866 At this time now specific answer for the issue was found. And now the issue is back after the kernel update. So whats happen here? And how can we get a stable Ethernet connection? Is there any patches or bugfixes available for the EMAC driver? Cheers SilvanInterrup numbers of Arria 10 EDAC
Hi, I try to enable the Error Detection and Correction (EDAC) for EMAC1 on my Arria 10 SoC device. I found the device tree entries for EMAC0 in the Linux kernel sources: emac0-rx-ecc@ff8c0800 { compatible = "altr,socfpga-eth-mac-ecc"; reg = <0xff8c0800 0x400>; altr,ecc-parent = <&gmac0>; interrupts = <4 IRQ_TYPE_LEVEL_HIGH>, <36 IRQ_TYPE_LEVEL_HIGH>; }; emac0-tx-ecc@ff8c0c00 { compatible = "altr,socfpga-eth-mac-ecc"; reg = <0xff8c0c00 0x400>; altr,ecc-parent = <&gmac0>; interrupts = <5 IRQ_TYPE_LEVEL_HIGH>, <37 IRQ_TYPE_LEVEL_HIGH>; }; Where do I find the interrupts used for EMAC1? Is there any documentation available? And does it require some changes in my Quartus project as well or is it fully covered by the Linux drivers?
Agilex5 EMAC to Fabric
I am trying to instantiate EMAC's that can be accessed over the Fabric: This builds successfully in the Qsys - however when adding it to the top level Verilog GHRD: ... wire outclk0_clk_wire; // 125MHz clock for Gb/s ethernet // emac0 definitions wire emac0_app_rst_reset_n_wire, emac0_mac_tx_clk_o_wire, emac0_mac_tx_clk_i_wire, emac0_mac_rx_clk_wire, emac0_mac_rst_tx_n_wire, emac0_mac_rst_rx_n_wire; wire emac0_mac_txen_wire, emac0_mac_txer_wire, emac0_mac_rxdv_wire, emac0_mac_rxer_wire, emac0_mac_col_wire, emac0_mac_crs_wire; wire [7:0] emac0_mac_rxd_wire; wire [2:0] emac0_mac_speed_wire; wire [7:0] emac0_mac_txd_o_wire; // emac1 definitions wire emac1_app_rst_reset_n_wire, emac1_mac_tx_clk_o_wire, emac1_mac_tx_clk_i_wire, emac1_mac_rx_clk_wire, emac1_mac_rst_tx_n_wire, emac1_mac_rst_rx_n_wire; wire emac1_mac_txen_wire, emac1_mac_txer_wire, emac1_mac_rxdv_wire, emac1_mac_rxer_wire, emac1_mac_col_wire, emac1_mac_crs_wire; wire [7:0] emac1_mac_rxd_wire; wire [2:0] emac1_mac_speed_wire; wire [7:0] emac1_mac_txd_o_wire; // Qsys Top module qsys_top soc_inst( ... .iopll_0_outclk0_clk (outclk0_clk_wire), .subsys_hps_agilex_hps_emac0_app_rst_reset_n (emac0_app_rst_reset_n_wire), .subsys_hps_agilex_hps_emac0_mac_tx_clk_o (emac0_mac_tx_clk_o_wire), .subsys_hps_agilex_hps_emac0_mac_tx_clk_i (emac0_mac_tx_clk_i_wire), .subsys_hps_agilex_hps_emac0_mac_rx_clk (emac0_mac_rx_clk_wire), .subsys_hps_agilex_hps_emac0_mac_rst_tx_n (emac0_mac_rst_tx_n_wire), .subsys_hps_agilex_hps_emac0_mac_rst_rx_n (emac0_mac_rst_rx_n_wire), .subsys_hps_agilex_hps_emac0_mac_txen (emac0_mac_txen_wire), .subsys_hps_agilex_hps_emac0_mac_txer (emac0_mac_txer_wire), .subsys_hps_agilex_hps_emac0_mac_rxdv (emac0_mac_rxdv_wire), .subsys_hps_agilex_hps_emac0_mac_rxer (emac0_mac_rxer_wire), .subsys_hps_agilex_hps_emac0_mac_rxd (emac0_mac_rxd_wire), .subsys_hps_agilex_hps_emac0_mac_col (emac0_mac_col_wire), .subsys_hps_agilex_hps_emac0_mac_crs (emac0_mac_crs_wire), .subsys_hps_agilex_hps_emac0_mac_speed (emac0_mac_speed_wire), .subsys_hps_agilex_hps_emac0_mac_txd_o (emac0_mac_txd_o_wire), .subsys_hps_agilex_hps_emac1_app_rst_reset_n (emac1_app_rst_reset_n_wire), .subsys_hps_agilex_hps_emac1_mac_tx_clk_o (emac1_mac_tx_clk_o_wire), .subsys_hps_agilex_hps_emac1_mac_tx_clk_i (emac1_mac_tx_clk_i_wire), .subsys_hps_agilex_hps_emac1_mac_rx_clk (emac1_mac_rx_clk_wire), .subsys_hps_agilex_hps_emac1_mac_rst_tx_n (emac1_mac_rst_tx_n_wire), .subsys_hps_agilex_hps_emac1_mac_rst_rx_n (emac1_mac_rst_rx_n_wire), .subsys_hps_agilex_hps_emac1_mac_txen (emac1_mac_txen_wire), .subsys_hps_agilex_hps_emac1_mac_txer (emac1_mac_txer_wire), .subsys_hps_agilex_hps_emac1_mac_rxdv (emac1_mac_rxdv_wire), .subsys_hps_agilex_hps_emac1_mac_rxer (emac1_mac_rxer_wire), .subsys_hps_agilex_hps_emac1_mac_rxd (emac1_mac_rxd_wire), .subsys_hps_agilex_hps_emac1_mac_col (emac1_mac_col_wire), .subsys_hps_agilex_hps_emac1_mac_crs (emac1_mac_crs_wire), .subsys_hps_agilex_hps_emac1_mac_speed (emac1_mac_speed_wire), .subsys_hps_agilex_hps_emac1_mac_txd_o (emac1_mac_txd_o_wire) ); ... The compilation process exits at the fitting stage with the following issue: Error(14566): The Fitter cannot place 1 periphery component(s) due to conflicts with existing constraints (1 NOC_FABRIC_ADAPTOR(s)). Fix the errors described in the submessages, and then rerun the Fitter. The Intel FPGA Knowledge Database may also contain articles with information on how to resolve this periphery placement failure. Review the errors and then visit the Knowledge Database at https://www.intel.com/content/www/us/en/support/programmable/kdb-filter.html and search for this specific error message number. Error(175001): The Fitter cannot place 1 NOC_FABRIC_ADAPTOR, which is within External Memory Interfaces for HPS Intel FPGA IP emif_hps_emif_hps_ph2_610_r3atsia. Error(16234): No legal location could be found out of 8 considered location(s). Reasons why each location could not be used are summarized below: Error(175006): There is no routing connectivity between the NOC_FABRIC_ADAPTOR and destination HMC Error(175022): The NOC_FABRIC_ADAPTOR could not be placed in any location to satisfy its connectivity requirements Error(175006): There is no routing connectivity between the NOC_FABRIC_ADAPTOR and destination SOC_HPS Error(175022): The NOC_FABRIC_ADAPTOR could not be placed in any location to satisfy its connectivity requirements Error(15307): Cannot apply project assignments to the design due to illegal or conflicting assignments. Refer to the other messages for corrective action. Error(16297): An error has occurred while trying to initialize the plan stage. Any pointers on what I have done wrong would be greatly appreciated!Agilex 7 FPGA-HPS latency problems
Greetings, we have questions about FPGA-HPS I/O on the Agilex 7M FPGA. The latency of FPGA->HPS writes is not behaving as we expect, and this is critical for our application. We are working with the DK-DEV-AGM039FES M-Series Development Kit. We have a small amount of data (1 cache line) that we want to send from FPGA logic to HPS for processing. Using the Cache Coherency Unit (CCU), we expect the Agilex 7 to route the write from FPGA directly to HPS L2 cache, as the cache line should be loaded for that address [1][2]. Instead, we observe that the cache line seems to get evicted, and the underlying memory is updated instead. The HPS will then pay full latency (230ns) of fetching the cache line from the underlying memory. We have provided some details of our test setup below. Q1: Can you help us determine if we have a configuration issue causing the cache to be flushed and underlying memory to be written instead? Q2: Does the Agilex 7 have a hardware bug that prevents the Cache Coherency Unit from functioning correctly, leading to increased latency in FPGA-HPS communication? See [4], [5], [7] about a documented bug. Q3: Do you have an estimate what kind of latency should be realizable for writing 1 cache line from FPGA logic to HPS (HPS accessing 1 word of it?) Q4: Is there a reference design and setup for Agilex 7 which can demonstrate low-latency access from FPGA to HPS cache? Alternatively, can you describe how we could demonstrate this on the evkit? [6] does not seem to directly demonstrate the achieved latency. Test setup: FPGA logic ====================== We have used the DMA IP as demonstrated in [6]. Additionally, we also tried our own IP block that generates 64-byte writes to the EMIF memory. These accesses go through Cache Coherency Translator IP block. The CCT CSR is configured as follows: ARDOMAIN = 0b01 # [1:0] ARBAR = 0b00 # [3:2] ARSNOOP = 0b0000 # [7:4] ARCACHE = 0b1111 # [11:8] AWDOMAIN = 0b01 # [13:12] AWBAR = 0b00 # [15:14] AWSNOOP = 0b000 # [18:16] AWCACHE = 0b1111 # [22:19] AxUSER_upper = 0b000001 # [28:23] = AxUSER[7:2] AxPROT = 0b001 # [31:29] We have tried many variations, including all the values for AxPROT, and setting AWSNOOP=0b001 (supposedly WriteLineUnique). We were not able to fix the latency by tuning these settings. Test setup: HPS configuration ============================= One HPS running Linux, we use u-dma-buf device tree fragment similarly to [6], to get a cacheable mapping to EMIF memory: #include "../socfpga_agilex7m_socdk.dts" / { reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; testbuf: testbuf@10000000 { compatible = "shared-dma-pool"; reusable; reg = <0x0 0x10000000 0x0 0x00400000>; label = "testbuf"; }; }; soc { udmabuf@10000000 { compatible = "ikwzm,u-dma-buf"; device-name = "udmabuf0"; size = <0x00400000>; memory-region = <&testbuf>; dma-coherent; }; }; }; We use kernel cmdline isolcpus=1 nohz_full=1 + sched_setaffinity() to isolate a CPU for our tests. From Linux user space, we map this memory with one of: int fd = open("/dev/udmabuf0", O_RDWR); /* Cached, or ... */ int fd = open("/dev/udmabuf0", O_RDWR | O_SYNC); /* Uncached / Device */ void* mapping = mmap(NULL, sz, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); In Arm Development Studio, we are able to verify that a cacheable (or uncacheable depending on request) virtual mapping to NP:0x10000000 is present in our process. In uncached mode, we measure about 230ns latency per access from 'mapping', reading a word in a loop through a volatile pointer. In cached mode, initially, one access completes in about 1.67ns. However, when the FPGA updates the memory (<= 64 bytes), the CPU read latency jumps to approximately 230 nanoseconds when the address is read again. The cache line should be present since the CPU busy-polls the address with reads. From Arm Development Studio "Memory" and "Cache" views, or by establishing both cached + uncached mapping and reading those, we can observe that the underlying memory indeed does get updated unexpectedly when the FPGA logic writes to the address. We expect only cache to be updated, but no write to memory. If the CPU itself writes to the cached mapping, we observe that only cache gets updated and the underlying memory does not (until line gets evicted much later). References ========== [1] Agilex 7 HPS Technical Reference Manual, section 7.3.5.3.: "If you do a Cache Allocate transaction, the CCU maintains coherency and allocates in the cache. This is useful when you want to maintain coherency and keep data available in the system with minimal latency, so the masters avoid traversing to the external memory for each transaction." ... "On cache hits, write data is stored in cache." https://www.intel.com/programmable/technical-pdfs/683567.pdf [2] AN 886: Intel Agilex 7 Device Design Guidelines, section 5.1.8 https://cdrdv2-public.intel.com/773606/an886-683634-773606.pdf [3] Setting up and Using Bridges Linux Example https://altera-fpga.github.io/rel-25.1/embedded-designs/agilex-7/f-series/soc/setup-use-bridges/ug-setup-use-bridges-agx7f-soc/#add-u-dma-buf-driver-to-create-cma-regions [4] KB 000086381: Why do I see cache coherency problems between the HPS and FPGA on Intel Agilex® 7 FPGA SoC designs in Intel® Quartus® Prime Pro Edition Software version 20.4 and earlier? https://www.intel.com/content/www/us/en/support/programmable/articles/000086381.html [5] U-Boot: "drivers: cache: ncore: Disable snoop filter": https://github.com/altera-fpga/u-boot-socfpga/commit/d192adafebcd5e742a229aedbdcc7d6957d68f02 [6] Setting up and Using Bridges Linux Example: https://altera-fpga.github.io/rel-25.1/embedded-designs/agilex-7/f-series/soc/setup-use-bridges/ug-setup-use-bridges-agx7f-soc/#add-u-dma-buf-driver-to-create-cma-regions [7] About snoop filters: https://www.intel.com/content/www/us/en/docs/programmable/814346/25-1/snoop-filters.html
