Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- FPGAs and Programmable Solutions
- Nios® II Embedded Design Suite (EDS)
- TSE Multicast Hash table issue

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Altera_Forum

Honored Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-06-2012
07:32 PM

1,571 Views

TSE Multicast Hash table issue

I have read & re-read the TSE hardware documentation describing the multicast address hash table and how it is supposed to work.

I have written a function to process an Ethernet multicast address per that documentation. What I find is that the calculated hash value as specified by the document does not result in a hash bucket entry that when set to 1, actually allows the reception of that ucast address. For example: The multicast address is 01-00-5E-7F-FF-FA (a standard mapping of IP address 239.255.255.250). The hash calculation on all 6 octets of address results in: 0b101100 (0x2C) if I understand what XOR means across the bit groups defined in the document. addr[07:00] = 0xFA the XOR of which is 0 addr[15:08] = 0xFF the XOR of which is 0 addr[23:16] = 0x7F the XOR of which is 1 addr[31:24] = 0x5E the XOR of which is 1 addr[39:32] = 0x00 the XOR of which is 0 addr[47:40] = 0x01 the XOR of which is 1 Now I note with some curiosity that the Linux code calculates this bit-reversed from my value and comes up with 0x001101 (0x0D). None the less, the apparently required value is actually 0x37 or 0b110111 as the hash index. I discovered this by binary searching the 64 possible values until I found the actual hash bucket that allowed a match on the multicast address. At this point I have zero clue. The documentation is pretty clear save for possible ambiguity on bit ordering but since the hash is based on octet partity it is really the address octet ordering that matters. And my code and the Linux code seem to have arrived at opposite ordering but both are wrong in so far as neither produce the value that works so I don't feel like a complete idiot. Has anyone actually made this work? Can someone confirm that multicast in Linux on the TSE actually works? Thanks.Link Copied

6 Replies

Altera_Forum

Honored Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-07-2012
09:36 AM

65 Views

Hello, all.

I have the same issue. The multicast address is 01-0C-CD-01-02-03 addr[07:00] = 0x03 the XOR of which is 0 addr[15:08] = 0x02 the XOR of which is 1 addr[23:16] = 0x01 the XOR of which is 1 addr[31:24] = 0xCD the XOR of which is 1 addr[39:32] = 0x0C the XOR of which is 0 addr[47:40] = 0x01 the XOR of which is 1 If I understand correctly, one should be written to the most significant bit of entry 0b101110 (0x2E). So, I try to write 0x80000000 to the address HASH_TABLE_ADDR + 0x2E: IOWR_ALTERA_TSEMAC_HASH_TABLE(TSE_BASE, 0x2E, 0x80000000); But in fact I do not receive any multicast frames... Note, that option "Include multicast hashtable" is turned on in my configurations, and MHASH_SEL bit is set to 0 (generate the 6-bit code from all 48 bits of the destination address). I have no ideas what hapens...
Altera_Forum

Honored Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-07-2012
10:17 AM

65 Views

Altera_Forum

Honored Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-07-2012
11:03 AM

65 Views

I found out, that '1' was not really written into Multicast Hash Table Register.

I tryed to write any values (0x1, 1<<31, etc...) using IOWR_ALTERA_TSEMAC_HASH_TABLE(TSE_BASE, 0x2E, <value>); But when calling reg_value = IORD_ALTERA_TSEMAC_HASH_TABLE(TSE_BASE, 0x2E); register value is always 0.
Altera_Forum

Honored Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-16-2015
03:35 PM

65 Views

Altera_Forum

Honored Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-17-2015
01:38 PM

65 Views

Hi all,

I am also having a bit of a issue enabling a specific Multicast address. I can disable all or enable all with functions: To enable all:```
for(i = 0; i< 64;i++)
{
IOWR_32DIRECT(ETHERNET_SUBSYSTEM_TSE_MAC_BASE, (0x100 + i*4),1); //or <<2
}
```

To disable all: ```
for(i = 0; i< 64;i++)
{
IOWR_32DIRECT(ETHERNET_SUBSYSTEM_TSE_MAC_BASE, (0x100 + i*4),0); //or <<2
}
```

And this works. But I would like to filter a specific Multicast address, in my case: 224.0.0.116 that has the Multicast MAC address: 01:00:5E:00:00:74 VALUE || XOR 0x01 || 1 0x00 || 0 0x5E || 1 0x00 || 0 0x00 || 0 0x74 || 0 This gives the binary: 10 1000 or in hexadecimal 0x28 I then disable all entry and try to enable just this one with the following code: IOWR_32DIRECT(ETHERNET_SUBSYSTEM_TSE_MAC_BASE, (0x100 + 0x28*4),1); and IOWR_32DIRECT(ETHERNET_SUBSYSTEM_TSE_MAC_BASE, (0x100 + 0x28),1); but it does not work. Has anybody tried this and succeded at it? Best regards, Filipe
Altera_Forum

Honored Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-28-2015
02:19 PM

65 Views

The MAC address occupied in the address bit in reverse order:

Therefore, add[7:0] should be = 0x01 => 1 add[15:08] should be = 0xc0 => 0 : : add [47:40] = 0x03 =>0- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

For more complete information about compiler optimizations, see our Optimization Notice.