Design not properly held in reset
Opened this issue · 5 comments
During some longer debugging (it turned out that the IPbus firmware was not the cause of our issue, but a reset signal on our side of the firmware that was asserted unexpectedly) we found that some parts of the IPbus firmware seem to not respect the global reset (rst_macclk in ipbus_ctrl), but continue to operate.
After some research, we came to the conclusion that this might be caused by the way udp_do_rx_reset generates the rx_reset signal that is used by build_arp, build_ping,...
rx_reset <= rx_reset_sig and not my_rx_valid;So whenever there is an incoming, valid data packet these parts of the IPbus IP core will leave there reset state.
Even though we did not notice any imminent effects, the behavior caused quite some confusion.
(When trying to reason why the reset is generated this way, it was noticeable that the the mac_rx_last indicator leads to a delayed reset inside udp_do_rx_reset. Our assumption would thus be that the reason for the code line cited above might be that we need to overwrite this delayed reset in case that there are two packets in short succession?)
This is a bit of a blast from the past! My memory, and it is 12 years ago now, is that this rather funky reset strategy dated from before we realised that depending on the specific MAC we could need an rx CDC FIFO and the issue was that the incoming packet was on a slightly faster clock than ours.
Prior to realising that the rx CDC FIFO was the eventual fix, I tried holding the rx side in reset until a packet started to arrive, hence this logic, then decided it was easier not to retire this logic.
As to how close packets are in short succession, there is the preamble and IFG around the frame at the Ethernet level which we don't see and which are longer than the stretching of the rx reset.
It is possible that delay in resets makes DHCP not started ?
Please see issue #227
No. There are two halves to the logic, packet reception and packet transmission. this reset logic is on in the receive domain and the address resolution (RARP or DHCP) is in the transmission side until a valid response is received.
There would be another question from our side regarding the behavior of the IPbus at boot-up, related to the reset and DHCP:
In our design we are planning to (deterministically) generate the MAC address at run time, shortly after the FPGA is configured (but this might take a couple of clock cycles). During this time we would like to keep the IPbus IP core in reset such that we do not accidentally send DHCP Discover packages (or ping replies or sth. else) with a wrong MAC address.
Based on the current state of the IP core, is it safe to assume that this would be working?
This is what the enable port is for on ipbus_ctrl.
Just hold it low until you are ready.