User Profile
User Widgets
Contributions
Re: Error (292014): Can't find valid feature line for core SLL_CA_HBC_T001_Hyperbus_Memory_Controller_10
Hello Pei Yuan, These errors indicate you are missing a valid license for the Intel Hyperbus Memory Controller IP core. The IP is included as an encrypted file and requires a specific license that is not covered by the standard or University Program licenses. Kindly contact your local Altera Sales Representative or distributor to request a license or an evaluation license for the IP. Regards, Pavee2Views0likes0CommentsRe: Agilex 7 I Series Development Kit: External hardware access error when programming
Hello Daniel, Glad to hear the issue got resolved. If you have a new question, feel free to open a new thread to get the support from Altera experts. Otherwise, the community users will continue to help you on this thread. Thank you.5Views0likes0CommentsRe: Inquiry: Reference Clock Jitter Limits for 1G Operation on Agilex 5
Hello, The 522fs RMS jitter (integrated from 10kHz to 20MHz, including spurs) for the GTS transceiver reference clock is a maximum value as defined in the Agilex 5 FPGAs and SoCs Device Data Sheet. This is generally treated as a strict specification to ensure reliable transceiver operation at all supported data rates. Your measured clock jitter (~1ps RMS) is higher than the specified maximum (522fs). While your system may still operate at lower data rates (such as 1G), this operation is not explicitly guaranteed by Altera. The official specification is set to ensure optimal performance, low bit error rates (BER), and compliance across all supported use cases. Regards, Pavee5Views0likes0CommentsRe: F-tile 10GBASE-R firecode FEC IP (Agilex 7)
Hello Rooney, You're right, Agilex 7 F-Tile Hard FEC IP does not support 10GBASE-R (Clause 74, Firecode FEC) for 10G rates. Unfortunately, Altera does not currently provide a soft IP core for 10GBASE-R Clause 74 (Firecode) FEC + PCS. For your requirements, you will need to implement your own Firecode FEC + PCS in FPGA logic, or obtain a third-party or open-source IP core. Regards, Pavee6Views0likes0CommentsRe: F-tile-ethernet-hard-ip TX/RX MAC Segmented Client Interface
Hello Ankit, The i_tx_mac_inframe signal segmented client interface is a bit vector (e.g., [15:0]) that marks which segments of the i_tx_mac_data bus contain valid data in the current clock cycle. Its transitions across cycles, together with its bit pattern, allow you to identify the Start of Packet (SOP) and End of Packet (EOP) locations. SOP, detected by a transition from all zeros to a non-zero value in i_tx_mac_inframe. The lowest set bit in i_tx_mac_inframe marks the location of the SOP in the data segments. EOP, detected by a transition from a non-zero value to all zeros in i_tx_mac_inframe. The highest set bit in i_tx_mac_inframe marks the location of the EOP in the data segments. For example, SOP: Cycle N-1: i_tx_mac_inframe = 16'h0000 Cycle N: i_tx_mac_inframe = 16'h00FF Interpretation: The change from all zeros to 16'h00FF means a new packet starts at cycle N. The lowest set bit in 16'h00FF (bit 0) marks the start of the packet in the segment. EOP Cycle N: i_tx_mac_inframe = 16'h00FF Cycle N+1: i_tx_mac_inframe = 16'h0000 Interpretation: The change from 16'h00FF to all zeros means the packet ends at cycle N. The highest set bit in 16'h00FF (bit 7 if only lower byte is used) marks the end of the packet in the segment. how to interpret i_tx_mac_data signals if i_tx_mac_valid == 1'b1 and i_tx_mac_inframe [15:0] == 16'h0 ? If i_tx_mac_valid is asserted (1'b1), but i_tx_mac_inframe is all zeros (16'h0), this means the interface is active/ready, but there is no valid packet data in the current cycle. The i_tx_mac_data signals should be ignored in this cycle—they do not contain valid data. This can occur during inter-packet gaps or when the MAC is otherwise idle. Hope this helps. Regards, Pavee0Views0likes0Comments