Created attachment 767 [details] Screencapture of Logic 2 and Pulseview MDIO read turnaround decoded incorrectly, attached image will clarify, last bit is written on the rising edge and then bits are read back on falling edges, so current the resulting decoded value is shifted left by one which is incorrect.
Is sampling MDIO values at the falling edge explicitly specified, or is it just done by convention? Could not spot any "official" literature on that subject in a quick search. IEEE802.3 seems to not be easily available, https://en.wikipedia.org/wiki/MDIO#Bus_timing_(clause_22) would not tell, neither does Total Phase. https://www.ousetech.com/?p=32 complains but resorts to timing adjustment instead. https://prodigytechno.com/mdio-management-data-input-output/ (in the Theory of Operation section) discusses falling edge for reads (when the PHY controls MDIO) but is not official. The snippets of official specs that I've seen, and other public documents, discuss (setup and) hold times instead, which seems rather weak. And Micrel PHYs are reported to not hold data that long (for the last bit?).
Should have mentioned that as well: sigrok had two MDIO decoder implementations, one as of 2015-06 and another as of 2016-04. Both of them exclusively used the rising edge, and the current implementation has not changed for six years. This needs more eyes, and a reliable source of information how to properly interpret the captured data. Getting example captures would also be useful. A screenshot is not suitable for reproduction, and does not allow to zoom in and out. (Relation of edges between MDC and MDIO are hard to spot in the image that you provided.)
Created attachment 769 [details] MDIO phy logic diagram Start and opcode bits Clause 22 read (0110) write (0101) Clause 45 read (0011) write (0001)
The rising edge clock the data out of the phy and the falling edge would then be a suitable sampling point. I wrote ATmega32U2 MDIO code accelerated with SPI and had to change the SPI phase to 1 before reading the data, then back to 0 after, and added a single clock cycle to get the phy to release the MDIO line. I do have the 802.3 documents since I work for a company doing embedded development ethernet switches.
(In reply to RikusW from comment #3) > Created attachment 769 [details] > MDIO phy logic diagram > > Start and opcode bits > Clause 22 read (0110) write (0101) > Clause 45 read (0011) write (0001) Clause 45 (0000) is used to set the 16 bit register address and (0010) to read and increment the address.
After looking at 802.3 it seems the best sampling point when readin from the phy would be just before the rising edge, but at 1MHz the falling edge sampling using SPI worked just fine but at higher frequencies it might not depending on how fast the phy clocks out the data after the rising edge.
Created attachment 770 [details] Saved capture of a write followed by a read
Created attachment 771 [details] Turnaround captures on oscilloscope
Created attachment 772 [details] MDIO read transition, clock = yellow
I see the Micrel phys specify MDC high to MDIO valid as 222ns which is rather slow and might not work with a fast mac MDIO controller. The Marvell phys have an instant response but 12ns including rise and fall times. https://ww1.microchip.com/downloads/en/DeviceDoc/ks8721b-bt.pdf - page 28
Created attachment 773 [details] 24MSPS capture of MDIO read
After going through everything again and looking at the oscilloscope capture I'd recommend sampling just before the rising edge when reading for both TA and data.
That is unfortunate. The .wait() logic has no concept of "just before an edge", which means that the PD implementation had to cease checking for edges (which performs well since the v3 API), and needs to inspect and hold each individual sample to have the sample before the edge available. Of course this needs only be done in the TA and read phases, but nevertheless it complicates the logic. And it will degrade the decoder's performance. The degree of slowdown depends on the oversampling of the captured signal. Might be acceptable or not even noticable for short captures. Thought I did something similar for the IEEE decoder. The attempt to cope with low oversampling in combination with phases where edges cannot be used made the implementation rather complex. Let's see when sombody picks up this task for MDIO. If you want to help implement this, or just want to implement it, then feel free to go ahead. Seems there are not many MDIO PD users when this has gone unnoticed for seven years.
The falling edge could be used but this will not get the first bit of TA correctly, I did have a quick look at the python decoder but that will take some time to understand.