User Profile
paveetirrasrie_Altera
Frequent ContributorJoined 4 years ago
User Widgets
Contributions
Re: TSE MAC+PCS (SGMII, Cyclone 10 GX): mdio_out/mdio_oen never toggle, no matter what I write
How MDIO transactions are triggered in this IP There is no separate "start" or "kick" bit. To access each PHY device, you write the PHY address to the MDIO register ( mdio_addr0 / mdio_addr1 ), followed by the transaction data (MDIO Space 0/1). The MAC allows up to two PHY devices to be mapped in its register space at any one time; subsequent transactions to the same PHYs do not require rewriting the PHY addresses, which reduces transaction overhead. PHY Management (MDIO) The key point: the MDIO transaction is triggered by the read or write to the MDIO Space window itself, not by writing to mdio_addr0/1 . MDIO Space 0 and MDIO Space 1 map to registers 0–31 of the PHY devices whose addresses are configured in mdio_addr0 and mdio_addr1 respectively. For example, register 0 of PHY device 0 maps to dword offset 0x80, register 1 to dword offset 0x81, and so forth. Reading or writing to MDIO Space 0 or MDIO Space 1 immediately triggers a corresponding MDIO transaction to read or write the PHY register. Only bits [15:0] of each register are significant; write 0 to bits [31:16] and ignore them on reads. MAC Configuration Register Space So the access sequence is: Write mdio_addr0 (offset 0x0F) with the Marvell 88E1111 PHY address (e.g. 0x00 or whatever your hardware straps set). Access the MDIO Space 0 window (dword offsets 0x80–0x9F), a write to 0x80 writes PHY register 0, a read from 0x80 reads PHY register 0, etc. That access is what fires the MDIO frame on the wire. The PCS-present caveat, this is likely your issue Because your core variation includes the PCS function, there is an important register-space conflict to be aware of: if your variation does not include the PCS function, you can use MDIO Space 0 and MDIO Space 1 to map to two PHY devices. If your MAC variation includes the PCS function, the PCS function is always device 0 and its configuration registers occupy MDIO Space 0. You can use MDIO Space 1 to map to a PHY device. MAC Configuration Register Space This means with core_variation=MAC_PCS : Dword offsets 0x80–0x9F (MDIO Space 0) → PCS internal registers, not your external Marvell PHY. Writes here configure the on-chip PCS, they do not produce MDIO frames on the wire. Dword offsets 0xA0–0xBF (MDIO Space 1) → your external PHY, addressed by mdio_addr1 (offset 0x10). If you have been writing to the 0x80–0x9F window expecting external MDIO frames, that explains exactly why mdio_out never transitions, those accesses are consumed internally by the PCS register interface and never reach the MDIO master. Corrected access sequence for your configuration Write mdio_addr1 (offset 0x10) = Marvell 88E1111 PHY address (e.g. 0x07 if that's your strap). Read/write dword offsets 0xA0–0xBF (MDIO Space 1). Offset 0xA0 = PHY register 0, 0xA1 = PHY register 1, etc. Each access to that window immediately fires the MDIO frame — you should see the preamble + frame on mdio_out in SignalTap. One more thing to verify: MDIO module must be enabled The TSE User Guide states the HW reset value for mdio_addr1 is '1' but this is applicable only if the MDIO option is turned on. If the MDIO option is turned off in your TSE IP instantiation, the HW reset value for mdio_addr1 is '0'. Why does the mdio_addr1 signal at offset 0x10 have a value of '0' for the Triple Speed Ethernet IP core? You mentioned useMDIO=true , so this should be fine, but it's worth confirming in your IP parameter editor that "Include MDIO module (MDC/MDIO)" is actually selected if it was accidentally left off, the MDIO master hardware simply isn't present regardless of what you write to the CSR. Also: ATX PLL frequency for GXB path Since you're using transceiver_type=NONE with external LVDS SERDES/TBI, this doesn't apply to your current config, but for completeness: you must configure the Arria 10 / Cyclone 10 GX Transceiver ATX PLL with an output clock frequency of 1250.0 MHz (instead of the default 625 MHz) when using the Arria 10 / Cyclone 10 GX Transceiver Native PHY with the Triple-Speed Ethernet IP. PCS/Transceiver Options Bottom line: switch your MDIO accesses from the 0x80–0x9F window to the 0xA0–0xBF window (MDIO Space 1), using mdio_addr1 for the PHY address, and you should immediately see activity on mdio_out .0Views0likes0CommentsRe: Problem with alt_2p5g_phy and polarity inversion.
Hello Stefan, Glad that you've found the workaround!! 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.1View0likes0CommentsRe: F-tile 10GE Ethernet Reference Design ISSP Error
Hello, Glad that the suggestion helped!! To answer to your follow up question: Why TX reads ~402.8 MHz, this is correct for your configuration o_clk_pll is a clock derived from the F-Tile Reference and System PLL Clocks IP associated with the Ethernet IP port, and its frequency is equal to the PLL frequency divided by 2. F-Tile Ethernet Hard IP User Guide With your System PLL at 805.6640625 MHz, o_clk_pll supports 402.83203125 MHz or higher for all Ethernet modes without FEC, with IEEE 802.3 BASE-R Firecode (CL74), or IEEE 802.3 RS(528,514) (CL91), and the system PLL must be 805.6640625 MHz or higher. F-Tile Ethernet Hard IP User Guide So o_clk_pll = 805.664 / 2 = 402.832 MHz, and since i_clk_tx is fed from o_clk_pll, a TX reading of ~402.8 MHz (after correction) is exactly right. Why RX reads ~161.1 MHz, and why this is NOT 156.25 MHz This is the key point of confusion. The ~161.1 MHz you're seeing for RX is not the PMA reference clock (156.25 MHz). It is the o_clk_rec_div64 recovered clock frequency for 10GE. The proper frequency for o_clk_rec_div64 (shown as rx_clkout in timing reports) is 161.1328125 MHz for 10G and 40G designs, and 402.83203125 MHz or 415.0390625 MHz for other rates. Why are the o_clk_rec_div and o_clk_rec_div64 ports improperly constrained when examining the timing reports of the F-tile Ethernet Intel® FPGA Hard IP? This tells me that in your design, i_clk_rx is being driven by o_clk_rec_div64 (the recovered clock), not by o_clk_pll. That is actually a valid and documented clocking arrangement. In IP version v5.0.0 (Quartus 24.1), the F-Tile Low Latency 50G Ethernet IP switched to using o_clk_rec_div64 (recovered clock) in the Rx PMA interface instead of o_clk_pll (system PLL clock) for the Rx MAC interface (i_clk_rx) here the system clock PLL output is used instead of the recovered clock. F-Tile Low Latency 50G Ethernet IP Release Notes So depending on which IP variant and version you're using, i_clk_rx may intentionally be sourced from the recovered clock rather than o_clk_pll. Summary of what you're seeing: TX ~402.8 MHz: i_clk_tx ← o_clk_pll = System PLL (805.664 MHz) / 2. Correct. RX ~161.1 MHz: i_clk_rx ← o_clk_rec_div64 (10GE recovered clock). Also correct for 10GE,this is not the PMA reference clock of 156.25 MHz; it is a separate recovered clock output at 161.1328125 MHz. The asymmetry between TX and RX clocks is expected in this topology. The 156.25 MHz PMA reference clock feeds the transceiver CDR/PLL hardware, it is not the same signal as i_clk_rx. 156.25 MHz is the recommended PMA reference frequency, supported when using FHT PMA or when auto-negotiation and link training is enabled. F-Tile Ethernet Hard IP User Guide It drives the PMA, not the MAC datapath clock. If you want both TX and RX to run from o_clk_pll (402.832 MHz), you would need to verify that i_clk_rx is connected to o_clk_pll rather than o_clk_rec_div64 in your design. Both are valid depending on your use case, but the register readings will reflect whichever source is actually connected.0Views0likes0CommentsRe: 8 port 10/25G ethernet interface in Stratix 10
Testing with a Fixed Ethernet Packet (Port-to-Port / Loopback) The quickest path is the E-Tile Hard IP for Ethernet hardware design example, which includes a built-in packet generator and checker. The hardware design example includes the E-Tile Hard IP for Ethernet IP core plus a PCS packet generator and checker that coordinates IP core programming, packet generation, and packet verification. 100GE PCS with Optional RS-FEC Hardware Design Example Components After compiling and programming the device via JTAG, you drive it through the Quartus Prime System Console using a Tcl script. The key commands you'll use are: start_pkt_gen — starts the packet generator; stop_pkt_gen — stops it. 100GE MAC+PCS with Optional (528,514) RS-FEC or (544,514) RS-FEC and Adaptation Flow Hardware Design Example chkphy_status — displays clock frequencies and PHY lock status; chkmac_stats — displays MAC statistics counter values; clear_all_stats — clears the statistics counters. 100GE MAC+PCS with Optional (528,514) RS-FEC or (544,514) RS-FEC and Adaptation Flow Hardware Design Example loop_on — turns on internal serial loopback; loop_off — turns it off. 100GE MAC+PCS with Optional (528,514) RS-FEC or (544,514) RS-FEC and Adaptation Flow Hardware Design Example To configure the packet generator for a fixed-size packet, use these registers: 0x1008 (Packet Size Configure) — bits [10:0] specify the transmit packet size in bytes. 10GE/25GE Design Examples Registers 0x1009 (Packet Number Control) — specifies the number of packets to transmit from the packet generator (HW reset value = 0xA). E-Tile Hard IP Intel® Stratix® 10 Design Examples User Guide: Ethernet, CPRI PHY, and Dynamic Reconfiguration 0x1010 (PKT_GEN_TX_CTRL) — bit [1] is the packet generator disable bit (write 1 to turn off, 0 to turn on); bits [5:4] = 01 selects fixed mode; bit [6] = 1 enables using register 0x1009 to stop the generator after a fixed packet count. E-Tile Hard IP Intel® Stratix® 10 Design Examples User Guide: Ethernet, CPRI PHY, and Dynamic Reconfiguration Switching Between 10G and 25G Rates (Dynamic Reconfiguration) The 10G/25G Ethernet Dynamic Reconfiguration design example demonstrates a dynamic reconfiguration solution for Stratix 10 devices using the E-Tile Hard IP for Ethernet IP core, supporting variants including 25GE with RS-FEC and PTP, 25GE, 10GE, and 1GE. 10G/25G Ethernet Dynamic Reconfiguration Design Examples The high-level procedure for each rate switch transition is: Assert (toggle) the sl_tx_rst_n and sl_rx_rst_n reset signals. 10GE/25GE MAC+PCS with RS-FEC Simulation Dynamic Reconfiguration Design Example Components Disable SERDES using PMA attribute code 0x0001. 10GE/25GE MAC+PCS with RS-FEC Simulation Dynamic Reconfiguration Design Example Components Trigger PMA analog reset. 10GE/25GE MAC+PCS with RS-FEC Simulation Dynamic Reconfiguration Design Example Components Change the transceiver TX bit/refclk ratio to the destination rate (refclk = 156.25 MHz), then change the transceiver RX bit/refclk ratio to the destination rate (refclk = 156.25 MHz). 10GE/25GE MAC+PCS with RS-FEC Simulation Dynamic Reconfiguration Design Example Components Reconfigure the registers for the Ethernet, RS-FEC, and transceiver blocks — the details of the changed register values are in the c3_reconfig.c file generated with the design example. 10GE/25GE MAC+PCS with RS-FEC Simulation Dynamic Reconfiguration Design Example Components Adjust the phase offset of the recovered clock using PMA attribute code 0x000E. 10GE/25GE MAC+PCS with RS-FEC Simulation Dynamic Reconfiguration Design Example Components Re-enable SERDES using PMA attribute code 0x0001. 10GE/25GE MAC+PCS with RS-FEC Simulation Dynamic Reconfiguration Design Example Components Deassert sl_tx_rst_n and sl_rx_rst_n, then for 10G/25G DR transitions wait for PIO_OUT[4:0] = 0x1F (o_sl_tx_ptp_ready, o_sl_rx_pcs_ready, o_tx_pll_locked, o_sl_tx_lanes_stable, o_sl_rx_ready, o_sl_ehip_ready all asserted). 10GE/25GE MAC+PCS with RS-FEC Simulation Dynamic Reconfiguration Design Example Components0Views0likes0CommentsRe: Free Licence for Max+PlusII
Hello Chris, Try this sequence: In MAX+Plus II, open Options → License Setup → System Info and record the ID it reports. On Windows, run ipconfig /all. For a NIC ID, enter the physical/MAC address as 12 hexadecimal characters without hyphens, colons, or spaces. Check both Ethernet and Wi-Fi adapters. Use the adapter ID specifically reported by MAX+Plus II; avoid VPN, virtual, disabled, or disconnected adapters. If the legacy generator still rejects it, try the ID used by your successfully generated 2020 license or the original licensed computer. The legacy system may not recognize a newer machine’s ID. Do not manually edit license.dat; the host ID is included in the license signature, so changing it invalidates the file. If you receive a license but MAX+Plus II cannot find it, save it as license.dat, select it under Options → License Setup, and verify the path. Regards, Pavee5Views0likes0CommentsRe: F-tile 10GE Ethernet Reference Design ISSP Error
Hello, The ISSP probe mismatch error is a consequence of those underlying failures — the probe is simply reporting that the aggregated status word doesn't match the all-pass pattern. Fixing the root causes below should resolve it. Root cause #1: RXCLK vs TXCLK frequency mismatch Your log shows: TXCLK: 402,840 KHz (~402.8 MHz) RXCLK: 161,130 KHz (~161.1 MHz) These should be equal in internal serial loopback. The TX clock running at ~402 MHz while RX is at ~161 MHz is a strong indicator that the RX CDR has not locked, it is not recovering the clock from the looped-back serial data. This directly explains why Rx Frequency Lock Status = 0 and RX PCS Ready = 0. rx_pcs_ready is an active-high asynchronous status signal for the RX datapath; it asserts when the RX datapath is ready to receive data, and deasserts when the reset signal asserts or during auto-negotiation and link training operation. Since your RX CDR hasn't locked, the datapath never becomes ready. Root cause #2: jtagd version mismatch, this is likely your primary problem You mentioned replacing the jtagd 24.1 executable with jtagd 25.1. This is a significant concern. The System Console TCL scripts in the 10GE reference design example were generated and validated against Quartus Prime Pro 24.1. Mixing a 24.1-compiled bitstream and 24.1 design scripts with a 25.1 jtagd can cause: JTAG master path resolution failures (the service master path changes between versions) Register reads returning sentinel/garbage values like 0xDEADC0DE , exactly what you see for Rx Frame Error and Rx AM LOCK ISSP probe reads returning stale or incorrect values I'd strongly recommend testing with a consistent toolchain: either use the full 24.1 jtagd with your 24.1 bitstream, or regenerate the design example entirely under 25.1 and use the 25.1 jtagd. The 0xDEADC0DE sentinel is a classic sign that a register read transaction did not complete successfully. Root cause #3: Known issue with Quartus Prime Pro 24.1 and RX ready signals There is a documented issue relevant to your exact Quartus version. Due to an unexpected behavior in the Agilex 7 F-tile Ethernet Hard IP 25G variant, there is a frequency mismatch between o_clk_rec_div and o_clk_revc_div64, which causes link loss for one clock reset sequence before o_rx_pcs_ready is available. This problem is fixed beginning with Quartus Prime Pro Edition software version 24.2. While that specific issue is documented for the 25G variant, the underlying reset sequencing sensitivity exists in 24.1 broadly and your 10GE design running on 24.1 may be hitting related reset-sequencing timing issues. Recommended diagnostic and resolution steps Restore jtagd 24.1 for your 24.1 bitstream and re-run the test. The 0xDEADC0DE register reads are the most urgent symptom to eliminate first, as they indicate the JTAG/System Console path is not communicating correctly with the IP. Confirm the reference clock. 156.25 MHz is the recommended frequency for all Ethernet modes and is the only supported frequency when using FHT PMA or when auto-negotiation and link training is enabled. Your RXCLK reading of ~161 MHz is close but not exactly 156.25 MHz × any standard division factor — this warrants checking your board's reference clock source and the F-Tile Reference and System PLL Clocks IP configuration. Upgrade to Quartus Prime Pro 24.2 or later if possible. The 24.1 → 24.2 fix for the reset/clock-recovery issue is directly relevant to your symptom of RX PCS ready not asserting after a soft reset. In summary: the ISSP probe mismatch is a symptom, not the root cause. The primary suspects are (1) the jtagd version mismatch corrupting register reads, and (2) the RX CDR not locking due to either a reference clock issue or reset sequencing timing in Quartus 24.1. Address those two first and the rx_pcs_ready and ISSP probe issues should resolve together.0Views0likes0CommentsRe: 8 port 10/25G ethernet interface in Stratix 10
Hello, Your part number is 1ST085EN2F43I2LG. This is a Stratix 10 E-tile device (TX variant). The 25G Ethernet Intel FPGA IP supports Stratix 10 L- and H-tile devices only. Stratix 10 devices with both E- and H-tile transceivers are supported, but the IP core can only utilize the H-tile transceiver. Since your device is an E-tile TX part, this soft IP is not the right choice. The E-Tile Hard IP for Ethernet is the correct IP for your board. It is the hard IP designed for your E-tile device, natively supports 10G/25G dynamic reconfiguration, RS-FEC (on 25G), MAC statistics counters, PTP timestamping, and packet generation/checking, all the features your test board requires. Regards, Pavee13Views0likes0Comments