Forum Discussion
New ContributorAgilex5 o_tx_ready and o_rx_ready not asserting
I'm working on a design for a video router, and having trouble with the transceivers. I have the premium devkit to test run the setup. This board has ES silicon, A5ED065BB32AE6SR0.
The design would implement 4 or 8 lanes of 12.5Gbps (later 17Gbps or faster), on the GTS XCVR, PCS Direct with IEEE_FLEXE_66 implementation. I followed the User Guide to implement the startup sequence (Reset_Sequencer is OK - it handshakes src_rst_req and src_rst_grant). Figure 65 was my guideline to develop the FSM to bring the Tx and Rx lane up and running.
The issue I'm observing:
The TX run-time reset sequence (UG Fig 56) completes: i_tx_reset asserted → o_tx_reset_ack asserts → i_tx_reset deasserted → o_tx_pll_locked asserts → src_rs_grant completes. But o_tx_ready never asserts (o_rx_ready likewise). As an extra measure against metastability, all status signals are 2-flop synchronized before use. When I hook up the Transceiver Toolkit, it brings the same channel up reliably. What additional condition gates o_tx_ready that isn't in Figure 56, or what should I look for to get the XCVR reliable up and running.
After the initial 'bring_up_sequence, I'll run 4kb packets at 64/66bit to minimize overhead, hence the FLEXE_66.
I'm kind of stuck
2 Replies
JonWay_alteraFrequent Contributor
Because both TX and RX ready remain low, I would first suspect a shared clock/reset prerequisite—i_system_pll_lock, i_refclk_ready, o_pll_lock, or missing/incorrect core clocks—rather than the IEEE_FLEXE_66 payload interface.
Probe these signaltap (with power up trigger). Set to Transitional.
i_refclk_ready
o_pll_lock
i_system_pll_lock
i_tx_coreclkin
o_tx_clkout (you cannot tap on clk signals. Instead use it to drive some counters, then tap on the counter to check for toggling activity)
o_tx_pll_locked
o_tx_reset_ack
i_tx_reset
i_src_rs_req
o_src_rs_grant
i_src_rs_grant
o_tx_ready
logitronapparently the clocks are running (TxCount_r and RxCount_r are counters in these respective clock domains).
nInit_Done is refClk_ready (PLL input), PLL_lock, rst_req and rst_grant are handshaking, TxReset_Ack and RxReset_Ack are behaving as expected, but as you can see ... Ready remains dead.
I noticed during setting up signaltap that the signals are all in the int_osc clock domain. And my LaneSequencer (the bring up sequence for GTS Tx and Rx) is in a 100MHz SysClk domain.
What do you mean with 'incorrect core clock'? There was an errata on version 25.3, but neither 25.3.1 nor 26.1.0 seem to be affected by this erratum?
