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

100G CMAC, LBUS Interface (PG 165)


I am looking into 100GbE CMAC. I'm trying to understand the LBUS receive user interface. I am confused about rx_mtyout* description. PG 165 says that "This bus
is only valid in cycles when both rx_enaout and rx_eopout are sampled as 1. When rx_errout and rx_enaout are sampled as 1, the value of rx_mtyout[2:0] is always 000. Other bits of rx_mtyout are as usual."

If we have 512b wide user interface with 128b in each segment and If LBUS rx_errout and rx_enaout are sampled as 1(I'm assuming that rx_enaout is also asserted), rx_mtyout value can be either "1000" or "0000". My question is 

1. what if the received packet length (in Byte) is not mod 8 and packet is out of the valid range(64 to CTL_RX_MAX_PACKET_LEN[14:0] bytes)? How to determine the frame length of the packet w/o using rx_errout for user logic. 

2. how to determine the packet is undersized or oversized(truncated) or packet has FCS error or Bad 64B/66B code?





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

1. So when the packet is wrong, You can only know about 8x length in the last segment. (64 or 128 bits)

(I guess it's because that the data is 64B66B coding. If there's error, maybe the block (64bits) data are wrong? Not sure about it)

Do you still care about the packet's length when it's a bad packet?

2. There're different RX status signals of CMAC IP for these errors, e.g. stat_rx_oversize, stat_rx_toolong, stat_rx_undersize, stat_rx_fragment, stat_rx_bad_code, stat_rx_packet_bad_fcs

0 Kudos