I think there is an easy fix. In the vMDIO_Interface_v1_20.v file, change the logic that drives the "read" logic to:
always @(posedge op_clock)
read <= (op_read | op_pos_read) & reg_cfg[MDIO_REG_INT_ON_READ] & addr_is_valid & is_page_en;
Hi RodolfoG_11 -
Thanks for the answer. I will checked the MDIO_Interface_v1_20.v file as you suggested, and I believe op_read is true when the opcode is read or pos_read because the op_read is based only on bit 2 of the opcode field (which is true if read or pos_read). However I'm not an expert in verilog so I could be reading the code wrong.
On further debug, I think the post-read increment is in fact driving the interrupt line for those MDIO registers where read trigger is configured. However, in the servicing the interrupt I read the MDIO register address being triggered using MDIO_Advanced_GetAddress(). The return from this call is a post-incremented address if pos_read MDIO frame opcode is used. Therefore, my read interrupt address decoding is off by +1 register.
The solution I'm persuing is to determine the MDIO frame opcode and adjust the register address returned from MDIO_Advanced_GetAddress() call depending on the read type. Of course the next problem is that MDIO Advanced doesn't provide access to the MDIO frame fields...
Yes, you are right. That would not help.
You might need to customize the component by adding a status register to capture the op_code.