The previous logic reset the mux before the end of the packet was
transmitted, effectively dropping almost all payload bytes for any
port other than the highest priority one.
The current FSM locks up when receiving an IPv4 packet that is not
addressed to the design itself. It gets stuck in `HEADER` with
block_done asserted, which resets bytecount to the payload length
instead of `BYTECOUNT_HEADER`, even when `crc_ok` or `rx_crc_error` is
asserted.
This commit fixes this by moving the reset condition (now based on
`rx_header_rcv`) to the bottom, and by properly handling the "not for
us" case by jumping to `DONE` directly.
On the TX side, we forgot to sync it entirely.
For RX, we need to delay the rx_active signal a bit to make sure
that it does not get negated before the last _valid strobe.
The problem arises in the following scenario.
There are two sources: HIGH-prio and LOW-prio. Current selection
(from last transaction) is LOW-prio. This one completes.
Next, both request at the same time. Data and tx_en from LOW-prio is
latched -> first word is taken from there. Now, arbitration does its
job and switches to high prio. All acks and data go here.
Result: First byte is from LOW-prio source, rest is from HIGH-prio.
This commit fixes this behavior by resetting the selected channel to
the highest priority one, preventing the switch from pulling it away
from the selected one as the high priority is the one that will get
selected by the switching logic anyways.
Fixes#13.
This reverts commit 9258edd0d97ebcf924d81e2db2b9bdae0b9e575a.
We cannot just look at tx_en as there will be one more ack
strobe after its deassertion, which needs to get through to the
real source.
Reopens#13.
For low ratios of the two clock domains, the slow clock domain would
receive incorrect data as the fast (PHY) clock domain's data output
would have already updated with the first bit of the next byte by
the time the slow (system) clock domain read it.
This fix registers the data in the source clock domain as opposed
to the destination clock domain. This is allowed because the valid
strobe is synchronized in a way to guarantee that data has been
valid for a while when it becomes asserted.
Additionally, `phy_out.rx_data` and `phy_out.rx_data_valid` are no
longer registered in the destination (system) clock domain as this
now introduces unnecessary latency. Also, this was broken the way
it was anyway as `rx_active` and `rx_error` would've also had to be
registered to keep all timings in sync.