Forum Widgets
Recent Discussions
VVP Protocol Converter Not work
Hello, I am looking for how to use the VVP protocol converter, by converting Altera Stream Video Lite to Avalon Streaming Video. I generate a simple pipeline with Protocol Converter to Frame Buffer on Cyclone 10 GX... Here's the settings of the converter, And the Register settings for this IP, For unknown reason, I am unable able to see the protocol converter ready to work by setting rx ready signal goes "high" on STP. Even when the tx side ready signal is OK. Readback the register, the mode is fine and the CTRL is bit 0 is set already.. What would be wrong on my settings? Please help. Thank you.
Cyclone IV GX PCIe Hard IP behaves differently on Intel Core I7 vs Xeon root complexes
Hello, I am working with a Cyclone IV GX (EP4CGX22) using the Altera PCIe Hard IP configured as PCIe Gen1 x1 with an Avalon-MM interface. The same FPGA image shows different behavior depending on the host platform. Platforms Tested Working Platform Intel Core i7-13700 Windows 11 Platforms Where the Issue Is Observed Supermicro X10SRA + Xeon E5-1620 v3 Supermicro X12SPL-F + Xeon Silver 4309Y PCIe Configuration The FPGA endpoint is configured as PCIe Gen1 x1 The Xeon platforms provide newer PCIe root complexes: Xeon E5-1620 v3 -> PCIe Gen3/4 capable slot Xeon Silver 4309Y -> PCIe Gen3/4 capable slots However, the link correctly negotiates down to: Link Width : x1 Link Speed : Gen1 (2.5 GT/s) which matches the FPGA endpoint capability. Common Observations On all platforms: PCIe enumeration succeeds Vendor ID and Device ID are detected correctly BAR resources are assigned correctly The device driver loads successfully The PCIe link is established successfully TLP as data input getting unexpected value Observed Difference Although the PCIe link is established correctly on all systems, the FPGA observes different transaction behavior on the Xeon platforms compared to the Intel Core i7 platform. The same FPGA image and software stack operate as expected on the Intel Core i7-13700 system, while different behavior is observed on both Xeon-based systems. Questions Are repeated accesses to BAR-space offsets after boot expected from BIOS/UEFI, Windows PCI bus enumeration, or other background PCIe activity? Has anyone observed different behavior between Intel Core desktop root complexes and Xeon/server root complexes when using the Cyclone IV GX PCIe Hard IP? Are there known interoperability issues between older Cyclone IV GX PCIe endpoints and modern Gen3/Gen4 server root complexes, even when the link successfully negotiates to Gen1 x1? Is there a recommended way to distinguish firmware/OS-generated PCIe accesses from accesses generated by the application or function driver? Any feedback or similar experience would be greatly appreciated. Thank you.
LVDS Output of FPGA
Hi all, I am using Arria 10 FPGA part number: 10AX066N2F40E1HG for one of my projects. There is a clock output from FPGA that goes to an external chip. This clock is configured as LVDS. Currently debugging an issue, and focused on enhancing the signal quality at the output of the FPGA. The output signal we measure in scope is not as good as we would expect. We expect a step signal, but the testing output shows a triangular signal! I have the following questions. 1) Is there settings/knobs I could tweak in my LVDS IP, or any other ideas to improve output signal quality? ( I learned about pre_emphasis setting), But other ideas could help. 2) Is there an inbuilt tool within FPGA to check the eye diagram or measure the output signal quality?instead of relying on an oscilloscope?. Note: I am using Quartus 2018 standard version. Let me know if you need further information. Thankyou.mipi csi2 tx, upper limit of video width
Hi, I am using Quartus ver 26.1 PRO Edition and investigating the MIPI CSI-2 TX IP on Agilex 5 E. I generated the CSI-2 Example Design and am running a RTL simulation. To change the video width, I modified the setting of FRAME_WIDTH_PIXELS in cfg_pkg.sv. When FRAME_WIDTH_PIXELS = 3840, the operation is normal. However, when FRAME_WIDTH_PIXELS = 7680, tready goes low and the system stalls. Is there an upper limit for FRAME_WIDTH_PIXELS? The IP setting is follow:
F-Tile PCIe Root Port 1x Gen3x4 - Configuration Read Type 0 receives no answer
Hello Support, I am using the Agilex 7F Dev Kit with F-Tile configured in Root Port Gen3x4. When I am doing a Configuration Write Type 0 to write the End Point BAR0 with FFFF_FFFFh, the end point send an answer , when I follow this write with a Configuration Read type 0 to read the BAR 0 of the End point I do not receive any answer. Is there any configuration which avoid the read data to go through the F-Tile ? Is there any problem with my Configuration Read type 0 command I have attached the STP file as well. Thank you for help. SergeArria 10 Native PHY 66:64 RX wrong word with valid asserted
I am using Arria 10 Native PHY in Basic Enhanced PCS mode at 12.5 Gbps for a custom protocol. The protocol layer is implemented in FPGA fabric. The Native PHY is intended to provide the serial transceiver path and the Enhanced PCS 66b gearbox only. The fabric provides one 66b block per clk_sys: 2-bit sync/control header + 64-bit payload The goal is a non-backpressure full-rate interface: one 66b TX block accepted every clk_sys, and one 66b RX block produced every clk_sys after RX lock. I've attached the .tcl to generate the core, but some of the key config parameters are: protocol_mode = basic_enh data_rate = 12500 enh_pld_pcs_width = 66 enh_pcs_pma_width = 64 TX 64b/66b encoder = disabled RX 64b/66b decoder = disabled TX scrambler = disabled RX descrambler = disabled RX block synchronizer = enabled TX FIFO mode = Phase Compensation RX FIFO mode = Phase Compensation double width = disabled 10GBASE-R insert/delete = disabled Interlaken deletion features = disabled Clocking: clk_sys <= tx_clkout(0); tx_coreclkin <= (others => clk_sys); rx_coreclkin <= (others => clk_sys); Controls: tx_enh_data_valid <= (others => '1'); rx_enh_fifo_rd_en <= (others => '1'); tx_pma_elecidle <= (others => '0'); 66b mapping: (inside a loop that iterates for every channel 'c') tx_parallel_data((c+1)*64-1 downto c*64) <= tx_data(c)(63 downto 0); tx_control((c+1)*2-1 downto c*2) <= tx_header(c)(1 downto 0); rx_data(c)(63 downto 0) <= rx_parallel_data((c+1)*64-1 downto c*64); rx_header(c)(1 downto 0) <= rx_control((c+1)*2-1 downto c*2); Observed in serial loopback simulation: With RX FIFO in RX Register mode, rx_enh_data_valid has periodic bubbles, apparently matching the 66:64 gearbox cadence. With RX FIFO in RX Phase Compensation mode, rx_enh_data_valid stays asserted, but rx_parallel_data periodically has a whole-word discontinuity. It looks like a 66b word is skipped/repeated, or the latency changes by one word. The event periodicity is about 160 ns, close to the expected 66:64 gearbox cadence. These two captures are from a sequence where I receive wrong data with rx valid asserted (the first is the tx'ed sequence and the second the received: To make the issue clear I mapped the word to a letter to make it easier to see the issue: In the capture above there is the tx and rx sequence, and can be seen where the pattern breaks compared to tx. My question is: For Arria 10 Native PHY Basic Enhanced PCS with enh_pld_pcs_width=66, enh_pcs_pma_width=64, and RX FIFO in Phase Compensation mode, is a continuous non-backpressure 66b RX stream supported? If yes, what configuration or clocking condition could cause a periodic one-word wrong while rx_enh_blk_lock, rx_enh_data_valid, and rx_control remain stable? Thanks in advance.
BER Degradation Observed When Enabling Multiple DFE-Adapted Channels on Arria 10 GX
Hello Altera Support Team / Forum Members, We are currently conducting a comprehensive transceiver channel test on our Arria 10 GX FPGA (part number: 10AX066K4F35M3SG and 10AX066K1F35I1SG). Our test setup and configuration parameters are as follows: Transceiver Configuration Rule: Basic (Enhanced PCS) PMA Configuration Rule: Basic Transceiver Mode: TX/RX Duplex Data Rate: 10 Gbps CDR Reference Clock Freq : 200MHz Number of CDR Reference clocks : 1 Selected CDR reference clock : 0 Test Pattern: External PRBS31 Measurement Tool: Transceiver Toolkit (Quartus Prime 20.2) Test Setup Description: Our system consists of a carrier board, an FPGA board, and a passive loopback connector. The carrier board contains no active components. The FPGA board is populated with various discrete interface components—including SDRAM, SRAM, FLASH, power sequencers, oscillators, clock buffers, and clock generators—to provide all necessary interfaces for the FPGA. The TX channels generated on the FPGA board are routed down to the carrier board, where they are looped back via the loopback connector and returned to separate RX channels on the FPGA. It should be noted that the TX and RX pairs are mostly located in different banks. The trace lengths of each channel along the loopback path vary between 8 inches and 11 inches. Reference Clock Architecture: We generate a 50 MHz signal using an on-board oscillator, pass it through a low-jitter clock buffer, and then feed the buffered output into a clock generator to produce the transceiver reference clocks. For the user clock, we apply a separate 100 MHz oscillator output directly to the Clkuser pin. Observed Behavior: During our test campaigns, we have achieved BER results on the order of 1e‑18 across many of the 36 looped‑back transceivers. In an effort to further minimize errors, we have selected pre‑emphasis, CTLE, and DFE settings within the Transceiver Toolkit that yield a zero‑error condition (i.e., no observed errors). Critical Issue: We are facing a significant inconsistency. When we test the 36 transceiver channels in four separate runs (9 channels per run), with VGA, EQ Control, and DFE parameters already set, we observe no errors for each channel during temperature cycling from 60 °C to 90°C (die temperature) and back down to 60 °C. Under these conditions, the BER remains zero. However, when we increase the number of channels with DFE adaptation enabled to the range of 12 to 15, we begin to observe errors on channels that previously exhibited no errors. Questions: What could be causing this degradation when the number of DFE‑adapted channels is increased? Are we exceeding some power, thermal, or resource limitation? Could there be an interaction between DFE‑enabled channels in adjacent banks or through the shared clocking/power distribution networks? Could this issue be attributed to silicon-level crosstalk between the DFE-adapted channels? More specifically, is it possible that enabling a larger number of DFE-adapted transceivers introduces additional noise coupling or interference within the FPGA silicon, potentially degrading the signal integrity of adjacent or nearby channels? If so, what would be the recommended approach to isolate or mitigate such effects in our current design and test environment? Additionally, we would like to ask: is there a known limitation on the number of transceivers that can reliably support a 10 Gbps data rate simultaneously across a wide temperature range ? Any guidance on debugging or resolving this issue would be greatly appreciated. Thank you in advance for your support. Regards, Onuravalon MM generator read issue
I'm using avalon MM BFM to stimuli my slave avalon interface, however, when doing u_avalon_MM_gen.mm_master_bfm_0.set_command_address(addr); u_avalon_MM_gen.mm_master_bfm_0.set_command_byte_enable(4'hF, 0); u_avalon_MM_gen.mm_master_bfm_0.set_command_request(REQ_READ); u_avalon_MM_gen.mm_master_bfm_0.push_command(); @(u_avalon_MM_gen.mm_master_bfm_0.signal_read_response_complete); data = u_avalon_MM_gen.mm_master_bfm_0.get_response_data(0); $display("[%0t] READ Addr=0x%08h Data=0x%08h", $time, addr, data); the data seem delay by 1 register transaction eg. READ addr=0 data=0 READ addr=4 data=1020001 <- this data should be at addr=0, but get_response_data(0) pop on the next addr return.data (get_response_data) has 3 ns delay from rising clock edge or from complete.data change
RX Mac segmented interface detailed information
I am using Ftile ethernet hard IP (400G configuration) . I complied the example test design with signal tap to monitor RX mac segmented interface and loaded on MA2700 . The kit is connected to a host with 400G capable NIC in it. I am using ping command and via wireshark I can see that host sends ARP request packet to the kit. As the ARP request packets are sent to the kit, I triggered STP and capture I have attached screenshot. you can see all data in the capture other than rx_mac data. rx mac data on clock -1 and 0 are as following -1 -> E39001000406000801000608AAEB6A17E390FFFFFFFFFFFFD5555555555555FB070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707 0 -> 070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707FDE831AB370000000000000000000000000000000000006501A8C0000000000000C801A8C0AAEB6A17 From wireshark I can see this ARP packet is 60bytes and all the fields matches with what I see in the o_rx_mac_data. Now I am trying to make sense of Rx mac segmented interface and I have following questions. rx mac inframe values are E000h and 000Fh meaning total 7 bits are 1 (logic high) indicating 56 byte packet but from payload is 60 bytes. So how do I equate for remining 4 bytes? in user guide o_rx_mac_eop_empty [47:0] signal is explained as "Indicates the number of empty bytes on the RX data signal, starting from the most significant byte (MSB). Valid only on EOP segments." I dont understand this statement completely so please help; as per signal tap waveform clock 0 is where packet ends and the value of bus is 4800h. I am not sure if and how this value can help equates for missing 4 bytes. Figure 44. Receiving Data Using the RX MAC Client Interface is little help- and small explanation below it (has typos i think) is not much help. Do you have more details and example for MAC segmented interface which you can share with me so that I can learn exact details on how to use this interface to receive incoming packets from Ftile. Using above signaltap screenshot and o_rx_mac_data values for clock -1 and 0; how do i detect sop? how do i use rx mac_sengemented interface to detect eop ? how do i use rx mac_sengemented interface detect exact length of ethernet frame which is being supplied during clock -1 and 0.