cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
351 Views
Registered: ‎11-26-2019

Tri mode Ethernet mac on kc705 no output

Hello,

 

I'm using a Tri-Mode Ethernet MAC v9.0 core with a kintex-7 kc705 board. The tool I use is vivado 2019.1. I have a custom IP that takes axi stream in/output. Because I just need the basic stuff, I disabled statistic vector and frame filters. All I want is to exchange raw ethernet data with PC. So I took the example design and replaced the pattern generator with my own code. In simulation it looks like that it should workethernet_no_output.PNG

As shown in the screenshot. tx_axis_fifo are provided by my IP, and as far as i know, the gmii interface connects to PHY. So if I can see my data on GMII it means that it should work. However, I can't see any packet from the FPGA with Wireshark. So please help me with this

1) Does statistic vectors influence the ethernet core, or I can remove them from the example design?

2) I tied serial_command to 0 just like in the example testbench. Will that influence the performance?

I create the packet with dest addr, src addr, type field and data, and I let the Ethernet core create padding and FCS. Even if I messed those up, I should still be able to see bad frames in wireshark. But instead there's nothing coming out of FPGA. I don't know where I should look at.

Thanks a lot,

William

5 Replies
Highlighted
Moderator
Moderator
328 Views
Registered: ‎08-25-2009

Hi @ma.william ,

First, have you tested the example design and see if you see any ethernet packets through wireshark?

This will be a good test to do so you have something to compare.

Have you been able to check MDIO interface and see if the link is up? Did you insert ILA to track on different interfaces on the packets?

"Don't forget to reply, kudo and accept as solution."
0 Kudos
Highlighted
Visitor
Visitor
313 Views
Registered: ‎11-26-2019

Hi nanz,

 

Thanks for the reply!

I have indeed loaded the exact example design on my board and tested it. With help of the pattern generator from the example design, I can see ethernet frames in wireshark coming from FPGA.

About MDIO interface, I basically preserved the entire code of the example design, so the management axi lite interface, the clock and reset generator, and the support block + FIFO are all the original code from the example design, except I enabled jumbo frame transmit and used the axi-lite clk for my ip and fifo. I don't know if I need to setup MDIO somewhere, I thought it's handled by the ethernet core. I also don't know what ILA is, but based on a quick search, it seems to give some warning messages for my design.

I get following messages in my design, but since it's the example design I thought it would be irrelevant, but I'll post them anyway.

[Netlist 29-345] The value of SIM_DEVICE on instance 'example_clocks/clock_generator/clkout1_buf' of type 'BUFGCE' is 'ULTRASCALE'; it is being changed to match the current FPGA architecture, '7SERIES'. For functional simulation to match hardware behavior, the value of SIM_DEVICE should be changed in the source netlist.

 

[DRC REQP-1839] RAMB36 async control check: The RAMB36E1 trimac_fifo_block/user_side_FIFO/rx_fifo_i/rx_ramgen_i/mem_reg has an input control pin trimac_fifo_block/user_side_FIFO/rx_fifo_i/rx_ramgen_i/mem_reg/ENARDEN (net: trimac_fifo_block/user_side_FIFO/rx_fifo_i/rx_ramgen_i/reset_out) which is driven by a register (trimac_fifo_block/rx_mac_reset_gen/reset_sync4) that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default.

 

[Vivado 12-1790] Evaluation License Warning: This design contains one or more IP cores that use separately licensed features. If the design has been configured to make use of evaluation features, please note that these features will cease to function after a certain period of time. Please consult the core datasheet to determine whether the core which you have configured will be affected. Evaluation features should NOT be used in production systems.

Evaluation cores found in this design:
IP core 'tri_mode_ethernet_mac_0' (tri_mode_ethernet_mac_0_block) was generated with multiple features:
IP feature 'eth_avb_endpoint@2015.04' was enabled using a design_linking license.
IP feature 'tri_mode_eth_mac@2015.04' was enabled using a bought license.

Resolution: If a new IP Core license was added, in order for the new license to be picked up, the current netlist needs to be updated by resetting and re-generating the IP output products before bitstream generation.

 

[DRC REQP-1839] RAMB36 async control check: The RAMB36E1 trimac_fifo_block/user_side_FIFO/rx_fifo_i/rx_ramgen_i/mem_reg has an input control pin trimac_fifo_block/user_side_FIFO/rx_fifo_i/rx_ramgen_i/mem_reg/ENARDEN (net: trimac_fifo_block/user_side_FIFO/rx_fifo_i/rx_ramgen_i/reset_out) which is driven by a register (trimac_fifo_block/rx_mac_reset_gen/reset_sync4) that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default.

 

[DRC RTSTAT-10] No routable loads: 4 net(s) have no routable loads. The problem bus(es) and/or net(s) are tx_stats_sync/data_out, rx_stats_sync/data_out, example_resets/chk_reset_gen/reset_out, and example_resets/gtx_reset_gen/reset_out.

 

There are also warning about some registers are optimized out and some ports are unconnected, but I don't think they are critical.

 

Thank you again.

0 Kudos
Highlighted
Visitor
Visitor
271 Views
Registered: ‎11-26-2019

Hi,

 

so just to make sure, I've reloaded the example design on my board. All works fine, but I discovered that the loopback only works if I send out ethernet frame with type 0x88b6 custom type. And the loopbacked package is 2 bytes longer than my original. My originals are 66 bytes long with correct fcs. The loopbacked are 68, and wireshark doesn't check fcs for custom types, so I don't know if the fcs from FPGA is correct.

 

However, when I use the length/type field to give the length, there is no loopback. When my package has 66 in the length field, no loopback at all. I want to use the length field to let the MAC remove padding for me. I don't know what caused that behavior. As said, this is the example design out of box.

0 Kudos
Highlighted
Visitor
Visitor
246 Views
Registered: ‎11-26-2019

Ok so I think I've found the problem. My IP is a data processing IP, so there won't be any output if there is no input.

 

The +2 byte loopback packet caught my attention yesterday. Instead of using normal ethernet crc32, the ethernet mac uses a 2 byte checksum called vss-monitoring ethernet trailer in wireshark. I don't know what that is and I've found little documentation about it online. Although in the ethernet mac manual it states that error frames will be delivered to the custom IP and it's the client's job to drop that frame, in the example design, the user FIFO drops error frames. For some reason, all my incoming ethernet frames with correct crc32 (verified by wireshark) are error frames for the ethernet mac, so it drops them all. And for some reason, when the ethernet frame type is 0x88b6, it stops checking for FCS and passes it along, so now I can see some output there.

 

However, due to this 2 byte checksum, if my data packet needs padding, the frame I receive is 62 bytes long, not 64, with the last 2 bytes as this checksum. The ethernet mac will pad my frame, but the FCS part is different than what I'd have imagined.

 

If there is some way to fix this issue and let the ethernet mac uses crc32, please tell me. Otherwise I'll have to use ethernet frames with 0x88b6 type and a 2 byte padding at the end.

 

Thanks again!

0 Kudos
Highlighted
Visitor
Visitor
221 Views
Registered: ‎11-26-2019

The problem seems to be something else.

 

I tried to send frames without fcs, with 2 zero bytes at the end, and with correct fcs. There is still no output. I changed the configuration to let the mac pass on the FCS to my ip, and I tied the rx_fifo_user signal to 0. Now all incoming frames should always be considered error free and stay in the FIFO.

 

At this point I don't know what I've missed. So any idea would be appreciated.

0 Kudos