How to configure/access Cyclone V HPS EMAC counters.

[Dzar]

I have a Cyclone V system where I use both EMAC0 and EMAC1 on the HPS. To test, my system is set up as a wire, essentially. Every packet that comes into EMAC0 is copied to EMAC1. Using wireshark I can demonstrate this and it's true. But when I look at the RX counters for EMAC0 (at address 0xff700XXX) I see very few frames/packets/bytes but thousands, if not millions, on EMAC1 (at address 0xff702XXX). And if I reverse the direction of my traffic, I see the RX counts on EMAC1 but little or no TX trafic on EMAC0.

Both are configured the same (the EMAC registers are configured the same related to MMC, DMA, etc.) so far as I can tell. I do see very infrequent counts (mostly when I ARP, it seems, but not when UDP/TCP packets fly by).

What can I do to get the EMAC0 counters working?

[MelvinSwee_T_Intel]

Similar to thread, click link below for discussions: 

https://forums.intel.com/s/question/0D50P0000428K1JSAU/reading-hps-emac-counters-not-reliable?language=en_US​

[Fawaz_Al-Jubori]

Hello,

The issue was re-produced. there should be no certain configuration to enable these counter registers.

We are still investigating this case.

Thanks

[Fawaz_Al-Jubori]

Hello,

You can refer to this link, where you can browse the available linux drivers:

https://github.com/altera-opensource/linux-socfpga/tree/master/Documentation/devicetree/bindings/iio/adc

Thanks

[Dzar]

I've perused the drivers and I believe I'm doing what they to to initialize the EMAC (and remember, I initialize EMAC0 and 1 the same). I think it could be that the Linux system is not using the mac counters, but using another method to "fake" the counters. I will dig into this, but it seems to me there should be an admission that EMAC0 counters are broken and there is no way to make them work, or there should be a published example that shows the counters working so I can duplicate that.

The counters are necessary to count errors. If I count frames, myself, I'll never see the errors which is what I really want to know.

Thanks,

Dave

[Fawaz_Al-Jubori]

Hello Dzar,

I have tried some settings before reading from frame counter. Please note this is from EMAC1, since my dev kit uses EMAC1 :(

However, you might try set these registers first:

https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410069057648.html

This is the control of MMC.

The interesting information here is, you can enable/disable broadcast frames, enable full/half preset counter, etc...

The interesting part when I tried memtool in linux was, each time I read, there was a reset to the counters. This MMC control allowed me to turn-off this feature, so I can read the counters without being reset.

This is the command I used: (this command initialize the MMC counters control)

memtool -32 0xFF702100=0x1f0

then I read the counter:

memtool -32 0xFF702188 1

And I can find the counter is increasing accordingly.

Please note the above bold addresses were tested since I am using EMAC1 only. You might need to change them to 0xFF700100 and 0xFF700188 for EMAC0, respectively.

Can you please try this on linux, if it works, then you need to apply these settings to DS-5 before you run your code.

I suspect mostly the reset configuration after each counter read you do. This option should be disabled to maintain the number of frames.

Thanks

[Dzar]

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.