Implement MDIO bus controller [Ethernet] #24
Conversation
There is now a test which connects the MDIO controller to a single PHY and verifies its correctness by feeding many random MDIO requests to the controller. Still TODO: - Add a test with multiple connected PHYs (two should be enough). - Simplify controller FSM. Many states can be merged. - Implement preamble suppression. - The clock generator seems to choke on dividers < 8.
| -- | MDIO bus request. | ||
| data MdioRequest | ||
| = MdioRead | ||
| { mdioSuppressPreamble :: Bool |
There was a problem hiding this comment.
Isn't this really fixed for a specific Phy? If that is this case I would say make this an argument when instantiating rather then inside each request.
There was a problem hiding this comment.
I just realized you could have multiple different PHYs on the bus where some support suppression and some do not.
| a single-bit preamble between frames. Your PHY may or may not support this. | ||
| Refer to the data sheet of your PHY. | ||
| The signals in the `MdioOutput` record are all registered and can |
There was a problem hiding this comment.
Afaik the original MDIO module required external IO registers. IO registers can be a pain to infer and without it they make consistent timing hard. Does this still support external IO registers?
There was a problem hiding this comment.
Yes, external I/O buffers are still supported, and actually, required. With "registered" I meant that they are not driven by combinatorial logic, not that they are already connected to platform-specific IOBs.
This PR implements an MDIO bus controller as specified in IEEE 802.3 Clause 22. Non-standard features such as preamble suppression and higher clock frequencies than 2.5 MHz are also supported.
For the MDIO pin outputs, I chose simple
mdioOandmdioTwires instead of using theBiSignalAPI. These nicely map to the bidirectional buffer inputs on most FPGAs (BBPUon ECP5,IOBUFon Xilinx FPGAs).mdioOis always driven0as MDIO must be connected to a pull-up resistor.The design is tested by connecting sample PHYs to the controller and randomly generating MDIO requests. Currently the
clash-protocolsDftest infrastructure is reused for this, as there is still limited support forCSignal(the controller does not handle incoming backpressure, just like a Wishbone slave). This should be changed in the future.Resource usage (Artix 7):
65 FF, 42 LUT