Forum Discussion

EV's avatar
EV
Icon for New Contributor rankNew Contributor
5 years ago

Agilex EMAC issue

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.

6 Replies

  • EBERLAZARE_I_Intel's avatar
    EBERLAZARE_I_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    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's avatar
      EV
      Icon for New Contributor rankNew Contributor
      5 years ago

      @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's avatar
        EV
        Icon for New Contributor rankNew Contributor
        5 years ago

        @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.