CMAC 2019.1 simulation stat_rx_remote_fault error despite alignment done

[namabo]

Hi everybody,

I'm working on a simulation of custom design with CMAC 2019.1.

I have a block that performs the Bring Up sequence as described in PG203, at point 2 it says:

2. Wait for rx_aligned then write the below registers

To perform this point I read from CMAC AXI control port the register:

STAT_RX_STATUS_REG_OFFSET 0x0204

To be more clear I report the register description:

Following the simulation waveform:

From the simulation I get:

1) 0xC0 -> stat_rx_local_fault and stat_rx_internal_local_fault,

2) 0xE0 -> stat_rx_local_fault and stat_rx_internal local fault,  and stat_rx_remote_fault

3) 0x23  -> the good news is that it is aligned (stat_rx_aligned and stat_rx_status) but I don't understand the stat_rx_remote_fault!

I put the gt_rx/pn pin connected togheter in order to make a loopback from the external side and I left the gt_loopback all to 0s.

Why Do I get stat_remote_fault?

If I try to send packet in AXI Stream TX CMAC port after 0x23, I'm able to receive the packet in the AXI RX port side, so why there is this bit to 1?

From PG203 it is not clear what this pin means and mostly which are conditions which can toggle this signal to 1.

Any suggestion is well accepted!

Thak you in advance.

[guozhenp]

Do you mean you connect GT TX p/n to RX p/n?

Do you assert ctl_tx_send_rfi?

[namabo]

Hi @guozhenp ,

thank you for your reply. Following my notes.

Do you mean you connect GT TX p/n to RX p/n?

Yes, I connected GT tX p/n and GT rx p7n togheter in the testbech 

Do you assert ctl_tx_send_rfi?

Yes, I assert the ctl_tx_send_rfi by mean of the axi4-lite port, following the

snapshot of the simulation, the really strange thing is that altough the axi trace seems ok and I receive a BRESP OKAY (i.e. 0x00), the ctl_tx_send rfi signal remains low (yellow traces)!

What's wrong? The ctl signal remains in this state forever (200us of simulation)!

Also, another think, if I uncheck the AXI4-Lite port on CMAC customization window, the design block, ctl* signals become available as pins, but there isn't any rx_aligned pin!!!

How can do Bring up sequence-Without AXI4-Lite Interface as describer on PG203 if there isn't a pin exposed in the design block!

Thank you!

[namabo]

Hi @guozhenp ,

thank you for your reply. Following my notes.

Do you mean you connect GT TX p/n to RX p/n?

Yes, I connected GT tX p/n and GT rx p7n togheter in the testbech 

Do you assert ctl_tx_send_rfi?

Yes, I assert the ctl_tx_send_rfi by mean of the axi4-lite port, following the

snapshot of the simulation, the really strange thing is that altough the axi trace seems ok and I receive a BRESP OKAY (i.e. 0x00), the ctl_tx_send rfi signal remains low (yellow traces)!

What's wrong? The ctl signal remains in this state forever (200us of simulation)!

Also, another think, if I uncheck the AXI4-Lite port on CMAC customization window, the design block, ctl* signals become available as pins, but there isn't any rx_aligned pin!!!

How can do Bring up sequence-Without AXI4-Lite Interface as describer on PG203 if there isn't a pin exposed in the design block!

Thank you!

[guozhenp]

Either asserting the input "ctl_tx_send_rfi" or writing the register should work.

This is TX/RX loopback design. So if you write the register to assert "ctl_tx_send_rfi", CMAC will be forced to transmit Remote Force and RX side will receive the Remote Fault.

I just checked CMAC IP core. I can see stat_rx_aligned without AXI4-lite interface selected.

[namabo]

Hi @guozhenp 

1)

Either asserting the input "ctl_tx_send_rfi" or writing the register should work.

This is TX/RX loopback design. So if you write the register to assert "ctl_tx_send_rfi", CMAC will be forced to transmit Remote Force and RX side will receive the Remote Fault.

Ok I got it, I'm asserting ctl_tx_send_rfi signal, I monitored the wrong lines, in fact those showed in the last post are about the input pins of the cmac block design. Analyzing example project I understand that cmac_usplus_0_axi4_lite_reg_map asserts the ctl_send_rfi signal (it is in OR with the cmac ctl signal external pin)

Here the line of the cmac_usplus_0_axi4_lite_reg_map block:

In light blue the most important signals,

- on the top you can see the sequence of axi reading operations, and the final value read 0x23,

- in the middle the rising edge of the ctl_tx_send_rfi signal

- and on the bottom the alignment and the stat_rx_remote_error signal

So I assure you I'm moving the signals as required...

2)

I just checked CMAC IP core. I can see stat_rx_aligned without AXI4-lite interface selected.

To be clear, the combination that hide the stat_rx_aligned signal is the selection of User Interface -> AXIS,

with this selection it doesn't matter if you check or uncheck AXI4-Lite port.

I'm working with: User Interface -> AXIS and AXI4-Lite control port enabled).

However, I can force to show the stat_rx_alignment pin in the block design modifying by hand the xml file in the line:

<xilinx:isEnabled xilinx:resolve="dependent" xilinx:id="PORT_ENABLEMENT.stat_rx_aligned" xilinx:dependency="((spirit:decode(id(&apos;MODELPARAM_VALUE.C_RS_FEC_TRANSCODE_BYPASS&apos;))= 0) and ((spirit:decode(id(&apos;MODELPARAM_VALUE.C_TX_OTN_INTERFACE&apos;))= 0) and (spirit:decode(id(&apos;MODELPARAM_VALUE.C_OPERATING_MODE&apos;)) != 1) and (spirit:decode(id(&apos;MODELPARAM_VALUE.C_USER_INTERFACE&apos;)) == &quot;LBUS&quot;)))">true</xilinx:isEnabled>

As you can note, this line will enable the stat_rx_aligned signal block design pin if you are using LBUS.

In this case I wrote true by hand and the signal appears, but honestly this is a trick!

3)

I think the cmac UI leads you in incoherent state. Intuitively, if I uncheck the AXI4-Lite control port regarless to the tx/rx method selected, I'd like to access all statistics and control information by pin block design. Instead in case I selectd the AXI4-Lite, I'd expect all statistics and control pins to disappear.

Thank you in advance.

[namabo]

Either asserting the input "ctl_tx_send_rfi" or writing the register should work.

This is TX/RX loopback design. So if you write the register to assert "ctl_tx_send_rfi", CMAC will be forced to transmit Remote Force and RX side will receive the Remote Fault.

Ok I got it, I'm asserting ctl_tx_send_rfi signal, I monitored the wrong lines, in fact those showed in the last post are about the input pins of the cmac block design. Analyzing example project I understand that cmac_usplus_0_axi4_lite_reg_map asserts the ctl_send_rfi signal (it is in OR with the cmac ctl signal external pin)

Here the line of the cmac_usplus_0_axi4_lite_reg_map block:

In light blue the most important signals,

[namabo]

- on the top you can see the sequence of axi reading operations, and the final value read 0x23,

[namabo]

- in the middle the rising edge of the ctl_tx_send_rfi signal

[namabo]

- and on the bottom the alignment and the stat_rx_remote_error signal

[namabo]

So I assure you I'm moving the signals as required...

2)

I just checked CMAC IP core. I can see stat_rx_aligned without AXI4-lite interface selected.

To be clear, the combination that hide the stat_rx_aligned signal is the selection of User Interface -> AXIS,

with this selection it doesn't matter if you check or uncheck AXI4-Lite port.

I'm working with: User Interface -> AXIS and AXI4-Lite control port enabled).

However, I can force to show the stat_rx_alignment pin in the block design modifying by hand the xml file in the line:

<xilinx:isEnabled xilinx:resolve="dependent" xilinx:id="PORT_ENABLEMENT.stat_rx_aligned" xilinx:dependency="((spirit:decode(id(&apos;MODELPARAM_VALUE.C_RS_FEC_TRANSCODE_BYPASS&apos;))= 0) and ((spirit:decode(id(&apos;MODELPARAM_VALUE.C_TX_OTN_INTERFACE&apos;))= 0) and (spirit:decode(id(&apos;MODELPARAM_VALUE.C_OPERATING_MODE&apos;)) != 1) and (spirit:decode(id(&apos;MODELPARAM_VALUE.C_USER_INTERFACE&apos;)) == &quot;LBUS&quot;)))">true</xilinx:isEnabled>

As you can note, this line will enable the stat_rx_aligned signal block design pin if you are using LBUS.

In this case I wrote true by hand and the signal appears, but honestly this is a trick!

3)

I think the cmac UI leads you in incoherent state. Intuitively, if I uncheck the AXI4-Lite control port regarless to the tx/rx method selected, I'd like to access all statistics and control information by pin block design. Instead in case I selectd the AXI4-Lite, I'd expect all statistics and control pins to disappear.

Thank you in advance.

[namabo · Accepted solution]

Finally I solved it.

Basically in my logic:

- I checked register STAT_RX_STATUS_REG in polling looking for 0x0003 (rx_aligned and status ok).

- If I get 0x0003 I release the ctl_tx_send_rfi and assert ctl_tx_enable.

The pg203 says to check only RX_ALIGN, so only RX_ALIGN BIT inside the register.

I'm in loopback so if I don't deassert ctl_tx_send_rfi myself after a HIGH rx_align, I will always receive remote fault(i.e. 0x0023)!

Now as soon as I receive rx_align bit high, I deassert ctl_tx_send_rfi, and I get the signal stat_rx_remote_fault just for a while, than it becomes low, and I start to TX, and check for RX.

For point 2) I will open a new thread

Regards