Forum Discussion

Dzar's avatar
Dzar
Icon for Occasional Contributor rankOccasional Contributor
7 years ago
Solved

Reading HPS EMAC counters not reliable

UPDATE: Seems EMAC1 is looking OK. The problem, there, was understanding what's meant by "good" in some cases. But EMAC0 looks like it's almost not counting anything. It's quite sporadic when I see anything increment, and this is while sending thousands of packets in/out of it.

------------------- original message, below ---------------

I'm using both HPS EMACs on a design and want to use the counters in them for various purposes. For example, 0xff700180 and 0xff702180 should be frame counters for EMAC0 and EMAC1, respectively.

But when I send a packet to EMAC0, I don't see this counter increment. And when I send, say 10, packets to EMAC1, it counts 3. I know the packets are being sent as they arrive at the destinations just fine, but the EMAC is not counting.

The same for other counters. In the above example, they are UDP packets. But the IP4 and UDP counters are not incrementing by the right number, either.

I'm using DS-5 debugger to read these registers/memory, as well as saving them in variables in my program code and these agree with each other, but are clearly wrong.

Any ideas? Has anyone seen these counters work, properly?

(I am able to read/write status registers and such, just fine, but these counters seem broken.)

  • Dzar's avatar
    Dzar
    7 years ago

    Final answer... Set the PR bit, not the RA bit. One does not need both, but the PR bit is the correct one if one wants counters to work. No documentation on this, sadly, but that's what we've deduced.

15 Replies

Show More
  • Dzar's avatar
    Dzar
    Icon for Occasional Contributor rankOccasional Contributor
    7 years ago

    I want to reiterate, as clearly as I can, that the registers are set exactly the same for EMAC0 and EMAC1. The same code is used to initialize both; the only difference is the base address passed in, essentially.

    I, too, I have tried various settings and I do see that the register get reset to 0 if that setting is set. But then it never counts as I stream packets. It will increase if an ARP happens. But not if I send IP packets.

    I see that Linux uses the reset on read (presumably because the counters are 64-bit yet the EMAC counters are 32 so that's how they deal with potential overflow). But there you are.

    I will do another test with Linux on Monday. I do believe that I saw valid counts for IP packets, but I will try sending packets with errors to see if they get counted. It could be that the Linux implementation is not actually using the MAC counters but the stack; if that's the case, it will not see errors that the MAC will throw out so that will be telling.

    My analysis of the Linux drivers is that they do nothing differently than what I am doing, myself.

  • Naji_Naufel_Arrow's avatar
    Naji_Naufel_Arrow
    Icon for Occasional Contributor rankOccasional Contributor
    7 years ago

    Can Intel route EMAC0 via the Fabric to a connector on the board and do the experiment using EMAC0?

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    7 years ago

    Hello NNauf,

    This is not applicable since there is no Hard PHY connected to EMAC0.

    Thanks

  • Dzar's avatar
    Dzar
    Icon for Occasional Contributor rankOccasional Contributor
    7 years ago

    It seems that I've uncovered and fixed the problem.

    The short answer is that when using the MAC in promiscuous mode (RA bit set in the filter config register), one also needs to set the PR bit in the same register.

    Bottom line is that the documentation is wrong on how the counters work, at best, and the MAC has a bug that it only counts when the MAC filters match even when in promiscuous mode, in my opinion.

  • Dzar's avatar
    Dzar
    Icon for Occasional Contributor rankOccasional Contributor
    7 years ago

    Final answer... Set the PR bit, not the RA bit. One does not need both, but the PR bit is the correct one if one wants counters to work. No documentation on this, sadly, but that's what we've deduced.