Triple speed ethernet IP core don't receive the RGMII data?

Firstly, the generated packets are repeated ARP request according with its standard.

Secondly, promiscuous mode is enabled in my design, and all frames should be received without address filtering. so I didn't configure the MAC address.

Do you perhaps have a pin assignment or board defect with your 2nd MAC and 2nd PHY ?

Assuming that your 2nd diagram that is incorrect, and that you have correctly implemented bidirectional buffer, I think your experiment should have worked. You can investigate further by using something like TCPDUMP/WireShark on each PC to confirm that PC2 is actually receiving anything (and that it matches what PC1 transmitted). But overall from your problem description, it sounds like the packet is getting corrupted/dropped on the 2nd RGMII or PHY. If I'm not mistaken, it sounds like you have never seen anything operate correctly on the 2nd port.

You can further dig into it with SignalTap (tap both sides of both MAC), but I think that would be possibly more time consuming to discover you have an underlying hardware problem. And if you are software inclined, I would suggest implementing the standard NIOS ethernet design and "Simple Socket Server" as a debug tool on just the 2nd MAC/PHY until it is working correctly.

--- Quote Start ---

Do you perhaps have a pin assignment or board defect with your 2nd MAC and 2nd PHY ?

Assuming that your 2nd diagram that is incorrect, and that you have correctly implemented bidirectional buffer, I think your experiment should have worked. You can investigate further by using something like TCPDUMP/WireShark on each PC to confirm that PC2 is actually receiving anything (and that it matches what PC1 transmitted). But overall from your problem description, it sounds like the packet is getting corrupted/dropped on the 2nd RGMII or PHY. If I'm not mistaken, it sounds like you have never seen anything operate correctly on the 2nd port.

You can further dig into it with SignalTap (tap both sides of both MAC), but I think that would be possibly more time consuming to discover you have an underlying hardware problem. And if you are software inclined, I would suggest implementing the standard NIOS ethernet design and "Simple Socket Server" as a debug tool on just the 2nd MAC/PHY until it is working correctly.

--- Quote End ---

Thank you for your reply.

I am sure pin assignment and board is correct, so the hardware problem should be eliminated. With my 2nd diagram, I really have implemented bidirectional buffer, but it don't still work. There is a limiting condition that PC2 in my experiment must not be install tools like WireShark. The internal loopback function of MAC IP core also be verified successfully, it indicates MAC works normally.

I guess the packet is getting corrupted on the transmitting path from MAC2 to 2nd port, through the packet can be output of 2nd port, but the receive side don't recognize it. If so, I am confused what caused this corruption, and how to localize the source of the problem?

--- Quote Start ---

I am sure pin assignment and board is correct

--- Quote End ---

How did you test this?

i.e. what is different between the configuration where you have confirmed the pin assignments and board is free of defects, and your problematic diagrams in your earlier post?

--- Quote Start ---

How did you test this?

i.e. what is different between the configuration where you have confirmed the pin assignments and board is free of defects, and your problematic diagrams in your earlier post?

--- Quote End ---

Recently, a similar module had been implemented successfully on the same board. Is there other reasons for the above phenomenon except for some hardware problem ?

--- Quote Start ---

Recently, a similar module had been implemented successfully on the same board. Is there other reasons for the above phenomenon except for some hardware problem ?

--- Quote End ---

A hardware problem or error on your part connecting the pins is by far the easiest problem. A quick sanity check on that would be to simply assign the 2nd PHY to the 1st MAC and vice versa (i.e. does the problem follow the PHY). If the 2nd PHY starts working and the 1st PHY stops working, you know that you have incorrectly configured/connected the 2nd MAC somehow.

Beyond hardware / pin connection problems, you should review your MAC signal connections, specifically the clocks/resets/streaming interface. It may be worthwhile to skim the Quartus output and look for warnings that are present for one MAC but not the other.

But in your shoes, I would revisit the known-working system and review differences between it and my broken system.

Good luck.

--- Quote Start ---

A hardware problem or error on your part connecting the pins is by far the easiest problem. A quick sanity check on that would be to simply assign the 2nd PHY to the 1st MAC and vice versa (i.e. does the problem follow the PHY). If the 2nd PHY starts working and the 1st PHY stops working, you know that you have incorrectly configured/connected the 2nd MAC somehow.Beyond hardware / pin connection problems, you should review your MAC signal connections, specifically the clocks/resets/streaming interface. It may be worthwhile to skim the Quartus output and look for warnings that are present for one MAC but not the other.But in your shoes, I would revisit the known-working system and review differences between it and my broken system.Good luck.

--- Quote End ---

I test my design according to your advice, and the result shows MAC2 works as the same as MAC. With my 2nd experiment, a net-analysis instrument （smartbits）substitutes for PC2 and detects the receive packets. As a result, the ARP request packets have a CRC error. every packet occupy 78 bytes. the anterior 42 bytes is correct but the rule of latter 36 bytes is unkown. The follow is the receive packet when a ping command sends at side of PC1. I don’t know why CRC error occur？“ FF FF FF FF FF FF B8 CA 3A 8A 83 5A 08 06 00 01 08 00 06 04 00 01 B8 CA 3A 8A 83 5A C0 A8 00 03 00 00 00 00 00 00 C0 A8 00 37 5F 45 64 50 05 23 82 82 CA A2 6E A0 0A 0A 0A 0A 00 00 00 00 C0 A8 00 03 B8 CA 3A 8A 83 5A 00 00 64 98 C8 4A”

--- Quote Start ---

I test my design according to your advice, and the result shows MAC2 works as the same as MAC. With my 2nd experiment, a net-analysis instrument （smartbits）substitutes for PC2 and detects the receive packets. As a result, the ARP request packets have a CRC error. every packet occupy 78 bytes. the anterior 42 bytes is correct but the rule of latter 36 bytes is unkown. The follow is the receive packet when a ping command sends at side of PC1. I don’t know why CRC error occur？“ FF FF FF FF FF FF B8 CA 3A 8A 83 5A 08 06 00 01 08 00 06 04 00 01 B8 CA 3A 8A 83 5A C0 A8 00 03 00 00 00 00 00 00 C0 A8 00 37 5F 45 64 50 05 23 82 82 CA A2 6E A0 0A 0A 0A 0A 00 00 00 00 C0 A8 00 03 B8 CA 3A 8A 83 5A 00 00 64 98 C8 4A”

--- Quote End ---

Further test result reveals the 4-byte CRC value is incorrect at sink while other field of packets is received accurately. The weird thing is that only 4-bits of CRC field occur error, moreover, the wrong 4-bits is always a “4” as the pciture shows. I can observe that the CRC value outputed by MAC1 is variable and normal when the CRC function of MAC IP is canceled. I‘m puzzled what caused the regular CRC error？

https://www.alteraforum.com/forum/attachment.php?attachmentid=8090

Since your error is 4-bits wide, and since RGMII is a 4-bit wide DDR bus, I think you need to look closer there.

Is the problem something simple like you didn't add the timing constraints for the 2nd port? Double check for timing violations anyway.