The algorithm used for computing the crc32:
1. compute crc32 over the 48-bits of mac dest. Address as follow:
crc := (OTHERS => `1`);
FOR i IN 0 TO 47 LOOP
feed := crc(31) XOR da(i);
crc := crc(30 DOWNTO 26) & (crc(25) XOR feed) & crc(24 DOWNTO 23) &
(crc(22) XOR feed) & (crc(21) XOR feed) & crc(20 DOWNTO 16) &
(crc(15) XOR feed) & crc(14 DOWNTO 12) & (crc(11) XOR feed) &
(crc(10) XOR feed) & (crc(9) XOR feed) & crc(8) &
(crc(7) XOR feed) & (crc(6) XOR feed) & crc(5) &
(crc(4) XOR feed) & (crc(3) XOR feed) & crc(2) &
(crc(1) XOR feed) & (crc(0) XOR feed) & feed; END LOOP;
2. Swap the bits in each bytes of the calculated crc32
3. Perform 1's complement of the crc32, and use the appropriate 6 bits from the
32-bits of the CRC for indexing based on MHASH_INDEX.
[mailto:firstname.lastname@example.org] On Behalf Of Alex Gonzalez
Sent: Thursday, September 07, 2006 4:54 AM
Subject: PMC RM9000x2 GL titan (yosemite) multicast address filtering
Hi, I am trying to configure the ethernet subsystem to filter out multicast
streams selectively, and I am running into some problems.
If anyone has done this before, could you try to answer the following questions?
1) For an incoming packet, the chip computes a non-inverted CRC32 calculation
over the destination MAC address, and uses the top 6 bits (using the default
values of MHASH_INDEX) to hash into the 64bin multicast hash table to decide
whether to filter the packet out or not.
As an example, if I set the multicast filter to accept packets from
188.8.131.52/255.255.255.252 ( MACs - 008a000a0a00 to 008a000a0a03 ).
The port configuration is,
multicast 64bin hash filter 4000:0008:0100:0000 (high, mid-high , mid-low , low)
With this configuration, the box sees streams like 184.108.40.206, but filters
I would like to make sure that the CRC32 algorithm that the chip is using is
the same I'm using. I have tried two different implementations that don't seem
to work (in both cases they filter out some multicast streams but not the
My CRC32 implementation details are:
CRC32(123456789) is 2dfd2d88, which is a bytes reversed, non-inverted result,
seeded on 0x00000000 and with a polynomial base 0x04c11db7 implementation.
CRC32(123456789) is cbf43926, which is a bytes reversed, result inverted,
seeded on 0xffffffff and with a polynomial base 0x04c11db7 implementation.
Has anybody tried this before? Could this be an endianness problem with my
CRC32 calculations (even though they both give the correct checksum over the
2) I will just mention my second problem just in case somebody else has seen
it. I have three ethernet ports, eth0, eth1 and eth2, and I use the same code
with the correct register offsets to write to the address filtering logic. I
can't write any values to eth1, even though it works perfectly for eth0 and