Problem with etherload stub

[SvOlli]

Hello,

I tried a partial rewrite of the etherload stub to get arp replies working. I succeeded, almost. Even though the code should reply always the same if arping'ed from the same host, the results vary.

Without knowing what happening inside the hardware, I can't go on any further.
Once this issue has been solved, I might be able to squeeze in support for ICMP, so the stub will reply to pings.
etherload.txt

[gardners]

What differences are you seeing? We did see some subtle bit corruption bug
with sending packets, but I don't know if that is still happening. Some
examples of the packets would be helpful in discovering the cause.

[Ben-401]

to see what is going on in the hardware maybe you could add checkpoint messages to the .a65 asm files? and view those messages using the serial-monitor. ie

jsr checkpoint
.byte 0,"GOT-TO-HERE",0

or even better populate the output message with values corresponding to the register values.

[SvOlli]

I don't think that it has to do with the C65 code. There are a lot of bit
flips, where I can't make up a pattern. I've attached a dump done with
wireshark.

btw: the sourcecode reveals who to tell the hardware how big the packet to
send is, but how can I tell how big the incoming packet is?

[gardners]

Yes, I recall there was a problem with bit-flips. I am not sure of the
cause of this. I am guessing that it will likely be a problem with the
delay relationship of the clock line versus the data lines from the FPGA to
the ethernet controller. It would be instructive to know if the bits are
in effect copied from the preceding 2-bit word in either direction (the
ethernet interface takes data 2 bits wide).

[gardners]

Datasheet for the ethernet interface IC on the Nexys4 is at:

http://ww1.microchip.com/downloads/en/DeviceDoc/8720a.pdf

TX data is latched when the clock goes high. The data should already be
present on the line at that point in time, i.e., should be provided when
the 50MHz clock goes low. At present, that is not the case.

Probably the best solution is to make the controller run at 100MHz, divide
that by 2 to generate the 50MHz clock for the ethernet controller, and then
drive the data explicitly on the low phase of the 50MHz clock, to be
certain that it is ready on time. There is probably a one or a couple of
days work for someone to implement and test that.

[gardners]

Have just taken a quick look: It seems possible to just invert the sense of the ethernet 50MHz clock to the PHY. Trying that (commit e788e25).

[Ben-401]

I am no expert, but I think the clocking of components needs revision.
ISE reports that there are gated-clocks, and clocks generated from combinational-logic(?).
This needs to be changed in my opinion.
From my experience we should be able to draw a solid line through the design to show which components are being clocked at 200M, 100M, 50M, and etc.

[Ben-401]

my opinion is that all components should be clocked at 200mhz (or more), and the chip-enable to each circuit be generated from a 4-bit counter (to give 100, 50, 25) driven by the incoming 200+ clock_in.

[gardners]

I agree the clocking can be improved. However, the pixel clock requires 192MHz, and the ethernet 50MHz, thus we cannot avoid having 2 clock domains. The CPU is 48MHz (pixelclock/4), which is generated by the FPGA's PLL. However, there are some other clocks lurking around the place that can probably be simplified, provided the process doesn't break anything.

[gardners]

We have just tried flipping the ethernet clock, as it looked like we were providing data on the wrong clock phase, but that is in fact not the problem.

Ben and my best guess now is that there is glitching on the TX side, and will try registering the outputs.

[gardners]

Implementing registering of ethernet tx signals in commit 44cddf8

[gardners]

I still haven't gotten around to testing if registering the signals has fixed the bit-flip problem.

[Ben-401]

Please assign this one to me. I will look into it after sdcard/fat32.

[lydon42]

As this is very old, and stuff like WeeIP, fetch and Haustierbegriff works, I deem it hereby closed.
If there are still topics with it, it might be better to create a new issue with clear description of shortcomings and reference this one.