Contributor
New Contributorhello,
thank you for the feedback.
May i know if ping is working before the change?
May i know what is the sampling clock for your signal tap?
For 1G speed you may need at least 250MHz sampling clock.
ContributorHi,
So far, the ping has never produced GMII toggles on SignalTap.
I have also tried using a PLL generated 250MHz clock to measure on signal tap (as can be seen in the following diagrams).
In the following, I disconnected the loopback and instead added a 'dummy' rx packet generator - then sent them to the EMAC rxd wire via Fabric:
gmii_rx_test_pattern u_rx_pattern (
.rx_clk(emac1_mac_tx_clk_o_wire),
.rstn(~system_reset),
.rxd(emac0_mac_rxd_wire),
.rx_dv(emac0_mac_rxdv_wire),
.rx_er(emac0_mac_rxer_wire)
);Which produces the following:
But it seems that on the Linux side these packets are not being acknowledged by the kernel:
root@localhost:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls card
lo: 115040 1600 0 0 0 0 0 0 115040 1600 0 0 0 0 0
eth0: 0 0 0 0 0 0 0 0 9136 56 0 0 0 0 0
eth1: 0 0 0 0 0 0 0 0 9316 58 0 0 0 0 0
eth2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0It also seems that sending ARPs do not produce GMII tx toggle in Fabric:
root@localhost:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.70.5 netmask 255.255.255.0 broadcast 0.0.0.0
ether ...
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 56 bytes 9136 (9.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 23
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.71.1 netmask 255.255.255.0 broadcast 0.0.0.0
ether ...
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 67 bytes 9838 (9.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 40
root@localhost:~# sudo arping -I eth1 192.168.70.5
ARPING 192.168.70.5
Timeout
Timeout ...Hello,
may i know how did you trigger the signal tap?
is it possible to trigger on falling edge for either one of these?
emac1_mac_rxdv_wire
emac0_mac_txen_wire
emac0_mac_rxdv_wire
emac1_mac_txen_wire
As for why the rx packets are not acknowledge by the kernel, you may need to check the packet generator. My suggestion would be to get a known-good packet and reconstruct the packet generator from that.
Since you are able to get the signals for rx side, could you please try that again for loopback mode? This will show how the packet should look like.
ContributorHi thanks for the suggestion,
So as you suggested to do, I have set trigger points on these two nodes:
emac0_mac_txen_wire
emac1_mac_txen_wire
When running SignalTap with these as triggers, I am seeing some toggling on the txd line:
I am noticing that for the first few seconds or so, this pattern will continue - and then it will settle here and not update again (i.e. enable will not toggle)
This all happens without making any network commands in the Linux terminal.
When making networking command through the linux terminal, these GMII signals still seem to not be affected still.
Maybe you have some idea? Perhaps the EMAC is expecting some specific GMII packets back? I have not yet hooked it up to the external PHY - so perhaps it needs some signals from an external PHY?
In terms of dummy packet generation, I have been using this module:
module gmii_rx_test_pattern #( parameter CLK_FREQ = 125_000_000 // RX clock frequency in Hz )( input wire rx_clk, // GMII RX clock (usually 125 MHz) input wire rstn, // Active low reset output reg [7:0] rxd, // GMII RX data to MAC output reg rx_dv, // Receive data valid output reg rx_er // Receive error ); // Pattern ROM (16 bytes example) reg [7:0] pattern [0:15]; initial begin pattern[0] = 8'h55; // Ethernet preamble pattern[1] = 8'h55; pattern[2] = 8'h55; pattern[3] = 8'h55; pattern[4] = 8'h55; pattern[5] = 8'h55; pattern[6] = 8'h55; pattern[7] = 8'hD5; // SFD pattern[8] = 8'hDE; // Example payload pattern[9] = 8'hAD; pattern[10] = 8'hBE; pattern[11] = 8'hEF; pattern[12] = 8'hCA; pattern[13] = 8'hFE; pattern[14] = 8'hBA; pattern[15] = 8'hBE; end reg [3:0] index; reg sending; always @(posedge rx_clk or negedge rstn) begin if (!rstn) begin rxd <= 8'd0; rx_dv <= 1'b0; rx_er <= 1'b0; index <= 4'd0; sending <= 1'b0; end else begin // Simple state machine to send pattern repeatedly if (!sending) begin rx_dv <= 1'b1; // Start of frame rx_er <= 1'b0; rxd <= pattern[0]; index <= 4'd1; sending <= 1'b1; end else begin rxd <= pattern[index]; index <= index + 1'b1; if (index == 4'd15) begin rx_dv <= 1'b0; // End of frame sending <= 1'b0; end end end end endmoduleI think it is OK. Please do correct me if not.
New Contributorhi,
great to know that you can see some tx signals toggling.
Sorry, i understand your statement here:
When making networking command through the linux terminal, these GMII signals still seem to not be affected still.
Do you mean, you are only able to capture the tx signals at the beginning. After that even if you send networking commands, the signal tap does not trigger? Does Linux acknowledge the tx packets?
Maybe you have some idea? Perhaps the EMAC is expecting some specific GMII packets back? I have not yet hooked it up to the external PHY - so perhaps it needs some signals from an external PHY?
For GMII signals, i believe there are no handshaking required. You can check that with the loopback design that you have. The loopback rx and tx signals should be identical.
