Agilex EMAC issue

[EV]

There seems to be a bad bug in the Agilex EMAC, at least in EMAC #0. The TU bit (bit #2) in the dmwgrp_status register works only once right after the init of the EMAC. That bit indicates if the EMAC DMA has gone into suspension because the next descriptor doesn't hold a valid packet. That info is sort of essential to determine if the DMA must be told or not to restart once a valid descriptor has been set-up with a new packet.  As a temporary work around we are using the TS bit field (Bit 22:20) and when the DMA reports it's in standby we assume it means it's waiting for a valid descriptor. Very far from being ideal or safe as the DMA can also report being in standby because of a transmit buffer overflow, i.e. an error condition.

[EBERLAZARE_I_Intel]

Hi,

May I know which version of Quartus, Uboot version and Kernel version you are using for this testing?

If using the GHRD, are you seeing the same issue?

Do you have the screenshot of the output/registers  status? I may need sometime to look into this issue.

[EV]

@EBERLAZARE_I_Intel ,:

Quartus Pro 20.4.0 and U-BOOT 2020.07-08704.

Doing the work with DS + JTAG and we only rely on U-BOOT to set-up the clocking and pin muxing.

We are not using GHRD but our own driver: the driver is OK on the Cyclone V, Arria 5 & Arria 10 (I am aware the Synopsis EMAC version is different between these and Agilex). To reproduce the problem, any working EMAC driver for the Agilex likely does the same as U-BOOT, which is to blindly write to the dmagrp_transmit_poll_demand register. That's even if the DMA is still going on. Wrap all instances of these with a "IF" the TU bit  of the dmagrp_status register having is 1, and the TX will not work (or only one packet will get out). Look at the TX descriptor chain and you will see new descriptors are parked, the DMA is in standby but not reporting it got into standby not having a descriptor to send out.  Write to dmagrp_transmit_poll_demand register and these parked packets will go out and once they are all out the TU bit will still not be set to 1.

[EV]

@EBERLAZARE_I_Intel 

I forgot to specify when the TU bit is set (within the "IF")  it is cleared by writing 0x4 to the dmagrp_status register because the bit is not self-clearing.

[EBERLAZARE_I_Intel]

Hi,

This seems like an uncommon issue, I shall check with our internal team on this issue. Could it possible that you would check with our GHRD if the issue is the same? 

[EV]

@EBERLAZARE_I_Intel , as I've previously indicated we are not using the GRHD.  We've already spent a fair amount of time isolating that issue and figuring out a work-around; so we're considering it closed on our side.  I've reported it solely for Intel's benefit.

[EBERLAZARE_I_Intel]

Hi,

Thank you for your concern, we have inform this to our internal team.