Forum Discussion
TSE MAC+PCS (SGMII, Cyclone 10 GX): mdio_out/mdio_oen never toggle, no matter what I write
Cyclone 10 GX (10CX220Y), Triple-Speed Ethernet IP: core_variation=MAC_PCS, transceiver_type=NONE (external LVDS SERDES, TBI), enable_sgmii=true, enable_use_internal_fifo=true, useMDIO=true.
Trying to read/write an external Marvell 88E1111 over MDIO via the MAC's control_port (System Console + JTAG-to-Avalon).
Verified working: basic CSR read/write (rev, scratch_pad), tse_rst=0 / xcvr_ready=1 (out of reset), mdc toggling correctly at 1.25MHz on the pin, MDIO_ADDR0 (0x0F) and MDIO_ADDR1 (0x10) are real R/W registers (write/readback matches), mdio_oen tri-state glue matches Intel's own reference template exactly.
Not working: I added (* preserve *) to mdio_in/mdio_out/mdio_oen and tapped them directly with SignalTap on TSEIP's own ports. With a falling-edge trigger on mdio_out, and while repeatedly writing MDIO_ADDR0/MDIO_ADDR1 and reading/writing both the phy0 (0x40+n) and phy1 (0x60+n) windows with genuinely varying values — mdio_out never shows a single transition. Since even a bare MDIO read frame must produce at least one falling edge (end of the all-1s preamble), this looks like no real MDIO transaction is ever being started from the CSR side.
What am I missing — is there another enable/start bit or busy/status flag needed to actually kick off an MDIO transaction on this core_variation/config? Any pointer to the MDIO register section for this exact IP version (Quartus Prime Pro 24.1) would help too.
1 Reply
- paveetirrasrie_Altera
Frequent Contributor
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 inmdio_addr0andmdio_addr1respectively. 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 SpaceSo 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_outnever 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_outin SignalTap.One more thing to verify: MDIO module must be enabled
The TSE User Guide states the HW reset value for
mdio_addr1is '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 formdio_addr1is '0'. Why does the mdio_addr1 signal at offset 0x10 have a value of '0' for the Triple Speed Ethernet IP core? You mentioneduseMDIO=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=NONEwith 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 OptionsBottom line: switch your MDIO accesses from the 0x80–0x9F window to the 0xA0–0xBF window (MDIO Space 1), using
mdio_addr1for the PHY address, and you should immediately see activity onmdio_out.