cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Adventurer
Adventurer
834 Views
Registered: ‎07-27-2018

CMAC 2019.1 simulation stat_rx_remote_fault error despite alignment done

Jump to solution

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:

register_rx.png

Following the simulation waveform:

 

simulation.png

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.

 

0 Kudos
Reply
1 Solution

Accepted Solutions
Adventurer
Adventurer
680 Views
Registered: ‎07-27-2018

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

View solution in original post

0 Kudos
Reply
5 Replies
Xilinx Employee
Xilinx Employee
764 Views
Registered: ‎05-01-2013

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

Do you assert ctl_tx_send_rfi?

0 Kudos
Reply
Adventurer
Adventurer
754 Views
Registered: ‎07-27-2018

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)!

axi_S_rfi.png

 


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!

 

 

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
733 Views
Registered: ‎05-01-2013

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.

0 Kudos
Reply
Adventurer
Adventurer
707 Views
Registered: ‎07-27-2018

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:

axi_wrapper_cmac_internal.png

 

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.

0 Kudos
Reply
Adventurer
Adventurer
681 Views
Registered: ‎07-27-2018

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

View solution in original post

0 Kudos
Reply