tify;text-indent: 40px;">大家好，
我有一个千兆以太网模块，其接口非常类似于32位的标准axi接口;
即mac_data_in（31：0_，mac_data_ready，mac_data_last，mac_data_valid等。
这是连接到8位的IP / UDP过滤器。它工作得很好，但由于8位与32位差异而没有进行优化。
现在，我已将所有转换为32位。
如果我的数据包长度> 52bytes，它可以很好地工作。
如果我有52bytes或更少，那么我会遇到问题。
它之前使用的是32bit / 8bit连接，因此问题不在于MAC端，而是在新的ip / dup过滤器模块上。
我有针脚指向数据包丢失的区域，但我需要你的帮助找到下面的原因。
让我解释：
1）我计算接收到的数据包的数量，当我到达以太网类型和IP类型时，我开始过滤。
所以你在下面看到，当rx_count是0x00C时，我需要过滤0x080045。
case rx_count是
当x“000c”=>时
--dataval_backup
2）在数据包长度> 52的情况下，它每次都有效
3）当数据包长度以下为原文
Hi All,
I have a gigabit ethernet module with an interface very similar to the standard axi interface in 32bit; i.e. mac_data_in(31:0_, mac_data_ready, mac_data_last, mac_data_valid, etc.
This was connecting to a IP/UDP filter in 8 bit. It worked perfectly, but was not optimised because of the 8bit vs 32bit discrepancies.
Now, I have converted all to 32bit. It works perfectly if I have a packet length > 52bytes. If I have 52bytes or less, then I get problems. It worked before with the 32bit/8bit connection, so the problem is not on the MAC side, but on the new ip/dup filter module.
I have pin pointed the area where the packet gets dropped, but I need your help finding the cause below. Let me explain:
1) I count the number of received packet and when I get to the ethernet type and IP type, I begin filtering.
So what you see below, when rx_count is 0x00C, then I need to filter for 0x080045.
case rx_count is when x"000c" => --dataval_backup <= mac_data_in(15 downto 0); --this is part of the ip_hdr if mac_data_in(31 downto 8) /= x"080045" then -- ignore pkts that are not type=IP next_rx_state <= WAIT_END; set_rx_state <= '1'; dbg_IPv4_RX <= '1'; end if; when others => -- ignore other bytes in eth header2) In the case of packet length > 52 it works every time
3) When packet length is <=52, dbg_IPv4_RX is set to 1 so the packet is dropped.
4) Previous message goes through all right
5) I allow 1 seconds before sending a new packet.
6) Simulation does not show this!!
Any ideas would be apreciated
