Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎10-06-2017

100G CMAC Pin and Status Register Mismatch


I am currently attempting to get the QSFPs working on the Alveo U200 board, Vivado 20.1.

My design attaches both the QSFPs, both full-duplex mode, with FEC enabled, AN/LT disabled, TX/RX Pause enabled, with copper 100G QSFP28 cable connected between them for testing. Both include GT subcore in core, and I have set relevant pins for both QSFPs:


Each of the QSFPs GTs are clocked from their own 161MHz GT clock, automatically connected when I add the board component in the block design.

gt_loopback_in pin on each = 0x0,

drp_clk tied to 0.

rx_clk input = its own gt_rxusrclk2 output.

core_rx_reset and core_tx_reset = its own usr_tx_reset and usr_rx_reset pins respectively.


When I pass data to the CMAC, it is not transmitted. I never see anything on the RX side.

I am performing the core bring up sequence using the AXIL interface, driven by the QDMA core and driver, and I'm seeing some strange behavior.

The values of the pins on my ILA do not match up to the values I am seeing in the CMAC status registers.

For example:

(Following bring up write 0x1 to 0x14, and 0x10 to 0xc, in both CMAC cores)

ILA shows RX_ALIGNED = 0, but reading register 0x204 shows 0x3 (RX_ALIGNED = 1 and RX_STATUS = 1).

(I see this value 0x3 in the register immediately following programming the bitstream. However, I know it can change, as previously it read 0xC in an older design when I was driving LPMODE and RESETL incorrectly...)

ILA shows STAT_RX_BLOCK_LOCK = 0x00000, but reading register 0x20C shows RX_BLOCK_LOCK_REG = 0x3FFFFF.

This is after repeated reads, so is not to do with latching values for example.

Can anyone help explain this behavior?




Tags (2)
0 Kudos
1 Reply
Xilinx Employee
Xilinx Employee
Registered: ‎05-01-2013

1. Please make sure your ILA scope the signals in the bottom module, just the outputs of CMAC in case there're some other logic between them

2. Please try GT PMA loopback first. Does it have the same problem in the loopback mode?