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.